▲

GN⁺: 나는 Makefile을 좋아함

 (switowski.com)
1P by neo 2달전 | favorite | 댓글 2개

  • 나는 Makefile을 좋아함. 처음 사용한 지 10년이 넘었음. 당시에도 오래된 기술처럼 보였음. 시간이 지나면서 새로운 빌드 도구들이 등장하고 사라졌지만, Makefile은 여전히 사용되고 있었음. 프로젝트에 참여하면서 익숙해졌고, 어느 순간 좋아하게 되었음. 현재는 새로운 프로젝트를 시작할 때 가장 먼저 사용하는 자동화 도구임.

  • Makefile을 좋아하는 이유는 동일한 명령어 세트를 구현하는 비공식적인 규칙을 따르기 때문임. 새로운 프로젝트를 접할 때 Makefile 파일이 있으면 make 또는 make build를 실행하고 make install을 실행하면 프로젝트가 빌드되고 설정됨. 또는 추가 단계에 대한 정보를 얻을 수 있음.

  • 내 프로젝트에서도 동일한 규칙을 적용하려고 함. 오래된 프로젝트 폴더를 열고 make dev를 실행하면 필요한 모든 단계를 수행하여 프로젝트를 빌드하고 개발 서버를 실행함. 다양한 기술을 사용했기 때문에 각 기술마다 다른 명령어가 있었음. Makefile을 사용하면 몇 달 또는 몇 년 동안 손대지 않은 프로젝트도 쉽게 관리할 수 있음.

  • Makefile은 간단함. 조건문, 플래그 또는 기타 복잡한 기능을 사용하지 않음. 대부분의 작업은 하나 이상의 셸 명령어로 구성됨. 몇 가지 함수가 있는 bash 스크립트를 작성할 수도 있지만, Makefile이 더 쉽고 빠르게 작성할 수 있음.

  • 대부분의 개인 프로젝트에는 다음과 같은 일반적인 작업이 포함됨:

    • dev: 개발 서버 시작
    • build: 프로젝트 빌드 (빌드 단계가 필요한 경우)
    • deploy: 프로젝트 배포/출판

  • 이 블로그에는 단일 타겟을 가진 간단한 Makefile이 있음:

    dev:  
  npm run dev

  • 더 복잡한 프로젝트에서는 다음과 같은 Makefile을 사용함:

    # 개발 서버 실행  
dev:  
  bundle exec jekyll serve --unpublished -w --config _config.yml,_config-dev.yml --livereload  

# 자산 빌드  
build:  
  npm run gulp build  

# 특정 폴더 감시 및 자산 처리  
watch:  
  npm run gulp watch -- --wip  

# 로컬에서 웹사이트 빌드, 암호화 및 Netlify 서버에 배포  
deploy:  
  JEKYLL_ENV=production bundle exec jekyll build; \  
  make encrypt; \  
  netlify deploy --prod  

# "_site" 폴더 암호화  
encrypt:  
  npx staticrypt _site/*.html -r -d _site

  • 위 예제에서는 phony 타겟의 존재를 무시하고 있음. dev, build, watch, deploy 또는 encrypt라는 파일이 있는 경우 Makefile이 예상대로 작동하지 않을 수 있음.

  • GNU Make는 매우 보편적임. Linux에서는 이미 설치되어 있을 가능성이 높음. MacBook에서도 명시적으로 설치한 기억이 없음. 다른 도구와 함께 설치되었을 것임. Make는 간단하고 다른 빌드 도구보다 추가 종속성이 적음. 제한된 환경에서 유용할 수 있음. Make가 이미 존재할 가능성이 높음. 그렇지 않으면 Makefile의 명령어를 수동으로 셸에서 실행할 수 있음.

  • 다른 빌드 도구를 반대하는 것은 아님. 새로운 빌드 도구를 발견하면 흥미로움. 하지만 여전히 Make를 사용하여 다양한 도구를 관리함.

GN⁺의 정리

  • Makefile은 다양한 프로젝트에서 일관된 명령어 세트를 제공하여 관리가 용이함.
  • 간단한 구문과 적은 종속성으로 제한된 환경에서도 유용하게 사용될 수 있음.
  • 다양한 빌드 도구와 함께 사용할 수 있어 유연성이 높음.
  • 비슷한 기능을 가진 도구로는 CMake, Ninja, Gradle 등이 있음.
▲
kayws426 2달전  [-]

종속성을 정의하지 않은 makefile 은 justfile 로 대체하면 더나은 사용성을 가져옵니다.

답변달기
▲
neo 2달전  [-]
Hacker News 의견

  • Make 사용에 대한 격려

    • Make를 잘못 사용한다고 낙담하지 말라는 의견
    • Make는 단순함이 장점이며, 작은 프로젝트에서는 큰 문제가 되지 않음
    • 대부분의 경우 올바른 방법을 신경 쓸 필요가 없으며, 필요한 만큼의 복잡성만 추가됨

  • Makefiles의 문제점

    • Makefiles는 다른 빌드 시스템보다 덜 나쁘지만 여전히 문제점이 많음
    • 빌드 시스템의 주요 문제점:
      • 너무 기본적임: 복잡한 프로젝트에서는 혼란이 생김
      • 너무 복잡함: 초기 지식과 관리가 과도하게 요구됨
      • 표준 라이브러리 부족: 모든 것을 직접 정의해야 함
      • 너무 제한적임: 필요가 변하면 다른 시스템으로 이동해야 함
      • 너무 많은 마법: 잘못 설계된 시스템의 특징
      • 암호화된 또는 일관성 없는 문법

  • Make의 장점

    • Make를 좋아하는 사람의 의견
    • Make는 단순한 DSL로 파일을 변환하는 명령어 모음임
    • Bash나 다른 쉘로도 가능하지만, Make가 더 간단함

  • PHONY 타겟 사용

    • mtime 기반 의존성 추적을 사용하지 않음
    • 타겟을 PHONY로 정의해야 함
    • 최근에는 just와 justfiles로 전환하여 더 간단하게 사용함

  • Make에 대한 열띤 논쟁

    • Make가 vi-vs-emacs 전쟁처럼 논쟁을 불러일으킴
    • Makefile을 최상위 빌드 시스템 드라이버로 사용하는 것이 스마트함
    • 다른 빌드 도구를 사용하더라도 Makefile로 표준화 가능

  • Make의 다양한 활용

    • Make를 다양한 작업 자동화에 사용함
    • 개인 웹사이트 빌드 및 배포에 Makefile 사용
    • Git push와 Git hook을 통해 Make 호출
    • PDF 파일 업로드 및 관리에 Makefile 사용

  • Make의 한계와 대안

    • Make는 작업 실행기로는 괜찮지만, 더 나은 대안이 있음
    • Make/Makefiles는 표준화되지 않음
    • 의존성 해결 불가, configure 스크립트 필요
    • mtime을 사용하여 입력이 최신인지 확인하지만, 문제 발생 가능
    • Unix 철학에 따라 설계되었지만, 현대 빌드 시스템에는 한계가 있음

  • Justfiles로 전환

    • Justfiles로 전환하여 Makefile의 복잡성을 피함

  • Makefile의 단순한 사용

    • Makefile의 단순한 사용을 지지하는 의견
    • 모든 것을 완벽하게 배우지 않고도 공유할 수 있음
    • GitLab CI 파이프라인이 Makefile을 대체한 경험 공유
답변달기