Make를 직접 사용하고 있습니까? [닫은]

그래서 makefile을 직접 만드는 방법과 2015 년에 어리석은 일에 대해 많은 의견 / 게시물 / 등을 보았습니다. CMake와 같은 도구를 알고 있으며 실제로 CMake를 자주 사용합니다. 문제는 CMake가 단지 당신을 위해 Makefile을 만들고 스스로 만드는 일을 없애는 것입니다. 물론 다른 많은 훌륭한 기능을 추가하지만 결국에는 Makefile이 추가됩니다.

그래서 내 질문은, Make 유틸리티 전체를 언급하는 make에 관한 '쓸모없는'이야기입니까, 아니면 자신의 Makefile을 수동으로 작성한다는 아이디어입니까? 나는 C / C ++ 개발을 위해 IDE를 전혀 사용하지 않으며 (emacs 만) 항상 Makefile을 작성했습니다.

Make가 구식이라고 생각되면 C / C ++ 개발자는 소규모 개인 프로젝트를 구축하기 위해 무엇을 사용해야합니까?

가장 큰 차이점은 CMake는 크로스 플랫폼 메타 빌드 시스템입니다. 단일 CMake 프로젝트는 일반적인 Unix / Linux makefile, Windows 용 Visual Studio 프로젝트, Mac 용 XCode 프로젝트 및 사용하거나 지원하고자하는 거의 모든 기타 메타 빌드 시스템을 생성 할 수 있습니다.

직접 또는 수동으로 makefile을 편집하는 것은 "더 이상 사용되지 않는다"고 말하지는 않지만 Windows로 포팅 할 필요가없는 Unix / Linux 작업을 수행하지 않는 한 아마하지 말아야 할 것입니다. Windows 이외의 파일로 이식하려는 경우 Visual Studio 프로젝트 파일을 직접 편집해서는 안됩니다. 이식성에 관심이 있다면 Scons 또는 CMake와 같은 메타 빌드 시스템을 배우는 것이 좋습니다.

되어 make정말 오래된?

나는 그렇게 생각하지 않습니다. 결국, make는 변경된 소스의 조건부 컴파일 등과 같은 원하는 모든 기능을 제공 할 수있을 정도로 강력합니다. 말하고 make, 구식이되었다 쓰는 사용자 정의 링커 스크립트가 구식이 된 말과 같은 것입니다.

그러나 원시 make가 제공하지 않는 것은 매개 변수 헤더 생성, 통합 테스트 프레임 워크 또는 일반적인 조건부 라이브러리와 같은 편의를위한 확장 기능 및 재고 라이브러리입니다.

반면, CMake일반 ELF 라이브러리 및 실행 파일을 생성하도록 직접 조정되었습니다. 미리 정의 된 절차에서 벗어날 때마다 CMake자신의 Makefile을 해킹 할 때와 마찬가지로 해킹을 시작해야합니다 .

ELF 로더를 알고있는 시스템의 일반적인 응용 프로그램보다 C ++로 훨씬 더 많은 것을 만들 수 있다는 점을 고려하면 CMake모든 시나리오에 적합하지는 않습니다. 그러나 표준화 된 환경에서 작업 CMake하거나 이러한 최신 스크립트 생성기 프레임 워크를 사용하는 것이 가장 친한 친구입니다.

항상 응용 프로그램의 전문성과 CMake프레임 워크 구조가 작업 흐름에 얼마나 잘 맞는지 에 따라 다릅니다 .

옛날 옛적에 높은 수준의 언어는 단지 아이디어였습니다. 사람들은 컴파일러를 구현하려고했습니다. 당시에는 하드웨어 제한이 심각했습니다. 그래픽 도구가 없었기 때문에 "일반 텍스트"가 입력 파일 형식으로 사용되었습니다. 컴퓨터에는 일반적으로 매우 작은 양의 RAM이 있으므로 소스 코드를 여러 조각으로 나눠야하고 컴파일러는 별도의 유틸리티 (사전 프로세서, 컴파일러, 어셈블러, 링커)로 분할되었습니다. CPU가 느리고 비싸서 비싼 최적화 등을 할 수 없었습니다.

물론 많은 소스 파일과 많은 유틸리티가 많은 객체 파일을 만드는 데 사용되므로 수동으로 무언가를 빌드하는 것은 엉망입니다. 도구의 설계 결함에 대한 해결책 (하드웨어로 인해 매우 제한됨) 사람들은 자연스럽게 스크립트를 작성하여 번거 로움을 없애기 시작했습니다.

안타깝게도 대본은 어색하고 어색했습니다. 제한된 하드웨어로 인한 도구의 디자인 결함에 대한 해결 방법 인 스크립트 문제를 해결하기 위해 사람들은 유틸리티를 발명하여보다 쉽게 ​​작업 할 수있게했습니다 make.

하나; makefile은 어색하고 지저분합니다. 제한된 하드웨어로 인해 발생하는 툴의 설계 결함에 대한 해결 방법이었던 makefile 문제를 해결하기 위해 사람들은 자동 생성 된 makefile을 실험하기 시작했습니다. 컴파일러가 의존성을 생성하는 것과 같은 것부터 시작; auto-conf 및 cmake와 같은 도구로 연결됩니다.

여기는 현재 우리가있는 곳입니다. 제한된 하드웨어로 인한 도구의 설계 결함에 대한 해결 방법을위한 해결 방법.

세기 말까지 기존 더미 위에 "해결 방법에 대한 해결 방법"계층이 몇 개 더있을 것으로 기대합니다. 아이러니하게도,이 모든 문제를 야기한 심각한 하드웨어 제한은 수십 년 전에 사라졌고 지금도 이러한 고풍스러운 혼란을 계속 사용하고있는 유일한 이유는 " 이것이 항상 수행 된 방법 "입니다.

make (Makefile을 통한 도구 또는 직접 사용)는 특히 "소규모 개인 프로젝트"에 적합하지 않습니다.

물론 여러 플랫폼을 대상으로하는 프로젝트를 포함하여 더 큰 프로젝트에 사용할 수도 있습니다. 로 다음 대상별 변수를 쉽게 사용자 정의가 다른 플랫폼에 구축하는 방법을 수 있습니다. 요즘에는 Linux 배포판에 크로스 컴파일 툴체인 (예 : mingw-w64 )이 제공되므로 Makefile을 기반으로 Linux에서 완전한 Windows 소프트웨어 패키지 (원하는 경우 설치 프로그램 포함)를 빌드 할 수 있습니다.

cmake 및 qmake 와 같은 도구 가 유용 할 수 있지만 문제가없는 것은 아닙니다. 일반적으로 라이브러리와 함께 응용 프로그램 자체를 빌드하는 데 적합합니다 (하지만 항상 라이브러리와 라이브러리를 사용하는 프로그램간에 적절한 종속성 검사를 수행하는 qmake에 문제가 있었지만). 작업 (설치 프로그램 작성, 문서 또는 번역 파일 생성 / 설치, 아카이브를 공유 라이브러리로 변환하는 등의 비정상적인 작업 수행) 종속성 추적make 과 같은 작업에는 약간의 노력이 필요할 수 있지만 이 모든 작업은에서 수행 할 수 있습니다 .

Qt Creator 및 Eclipse와 같은 IDE도 Makefile 기반 프로젝트를 가져올 수 있으므로 IDE 사용 개발자와 공유 할 수 있습니다. Qt Creator IDE는 C ++ IDE만큼 우수하다고 생각하지만 Emacs에서 더 효과적으로 사용하기 위해 시간을 보낸 후 더 많은 Ada 개발을 수행하고 있기 때문에 모든 것을 위해 Emacs를 선호하고 있습니다. 에 대한 질문과 관련하여 makeMakefile의 포스트 링크 단계 로 다음 과 같이 로드 된 내 TAGS 파일 ( Emacs의 심볼 탐색 용)을 업데이트합니다 M-x visit-tags-table.

find $(SRC_DIR) $(TEST_DIR) -regex ".*\.[ch]\(pp\)?" -print | etags -

또는 Ada 개발의 경우 :

find $(SRC_DIR) $(TEST_DIR) -name "*.ad?" -print | etags -

이 답변은 @lxrec 답변을 보완합니다.

Makefile은 소스 코드에서 프로그램 / 라이브러리를 만드는 것뿐만 아니라 많은 용도로 사용할 수 있습니다. CMake 또는 autotools와 같은 빌드 시스템은 코드를 가져와 사용자의 플랫폼에 맞는 방식으로 빌드합니다 (예 : 라이브러리 찾기 또는 올바른 컴파일 옵션 지정). 예를 들어, 다음과 같은 일부 릴리스 작업을 자동화하는 데 도움이되는 makefile이있을 수 있습니다. git에서 파생 된 버전으로 코드가 포함 된 zip 파일을 빌드하십시오. 코드에 대해 테스트를 실행하십시오. zip 파일을 일부 호스팅 서비스에 업로드하십시오. automake와 같은 일부 빌드 시스템은이를 수행하는 쉬운 방법을 제공 할 수 있지만 다른 시스템은 그렇지 않을 수도 있습니다.

즉, makefile을 사용해야한다고 말하는 것은 아닙니다. 스크립팅 언어 (쉘, 파이썬 등)를 이러한 작업에 사용할 수 있습니다.

나는 인간의 서면 Makefile-s가 특히 다음과 같은 경우에 더 이상 사용되지 않는다고 생각하지 않습니다 .

1. POSIX make를 사용하여 휴대용 Makefile
2. 또는 GNU make 4를 사용하면 Makefile생성기에서 제공하는 멋진 기능을 효율적으로 코딩 할 수있는 매우 흥미로운 기능, 특히 GUILE 스크립팅 기능을 제공합니다 (autotools 또는 Cmake의 기능은 GNU make의 Guile 사용자 정의로 쉽게 작성할 수 있다고 생각합니다) ). 물론, 지불해야하는 가격은 GNU make 4 (IMHO)가 아니라는 것입니다.

텍스트 파일이 더 이상 사용되지 않는 것처럼 Makefile은 더 이상 사용되지 않습니다. 모든 데이터를 일반 텍스트로 저장하는 것이 항상 올바른 방법은 아니지만 원하는 모든 작업이 Todo List이면 일반 텍스트 파일이 좋습니다. 좀 더 복잡한 경우 Markdown 또는 XML과 같은 더 복잡한 형식이나 사용자 정의 이진 형식 또는 그 사이의 모든 것을 원할 수 있지만 간단한 경우 일반 텍스트가 정상적으로 작동합니다.

마찬가지로, 당신이 원하는 g++ -g src/*.c -o blah -W -Wall -Werror && ./blah모든 것이 항상 쓰지 않는 방법이라면 , 손으로 쓴 Makefile이 완벽합니다!

이식성을 직접 관리 할 필요가없는 이식성이 뛰어난 무언가를 만들고 싶다면 Autotools와 같은 것이 올바른 Makefile을 생성하기를 원할 것입니다. Autotools는 다양한 플랫폼에서 지원되는 기능을 감지합니다. Autotools로 빌드 된 표준 C89로 작성된 프로그램은 거의 모든 곳에서 컴파일됩니다.

프로젝트가 단순하고 파일이 거의없는 경우 make 파일이 필요하지 않습니다.

그러나 프로젝트가 복잡하고 많은 메모리 영역을 사용하고 파일이 많으면 주소 지정 가능한 메모리의 올바른 지점에 각 메모리 영역을 배치해야합니다. 사소한 변경이있을 때마다 모든 파일을 다시 컴파일하지 않는 것이 좋습니다. 하나의 파일로 만든

최소한의 번거 로움과 키 누르기 실수로 오래된 파일 / 컴파일 / 링크 / 설치를 지우려면 makefile이 정말 좋습니다.

'실제 세계'프로젝트에 들어가면 거의 1 ~ 2 개의 파일이 아니라 수백 개의 파일이됩니다. makefile은 항상 올바른 조치를 수행하고 불필요한 조치 (디버그 된 후)를 수행하지 않으므로 하나의 간단한 명령 만 입력하면 makefile이 모든 작업을 수행합니다.