☰

automake와 autoconf가 코드를 컴파일하는 표준 방법입니까?

tag-icon • tag-icon compiling programming
automake와 autoconf가 코드를 컴파일하는 표준 방법입니까?

저는 가끔 소스에서 애플리케이션을 컴파일하고 다음을 사용해 왔습니다.

./configure
make
sudo make install

./autogen.sh하지만 최근에는 구성을 생성하고 스크립트를 만들어 실행하는 것으로 나타났습니다 .

C/C++/C#(모노) 컴파일을 단순화할 수 있는 다른 방법은 무엇입니까? 좀 늙어보이네요. 새로운 도구가 있나요? 선택이 주어진다면 어떤 것을 사용해야 합니까?

답변1

Autoconf와 Automake는 Unix 발전 문제를 해결하도록 설계되었습니다.

Unix가 다른 방향으로 이동함에 따라 이식 가능한 코드를 원하는 개발자는 다음과 같은 코드를 작성하는 경향이 있었습니다.

#if RUNNING_ON_BSD
Set things up in the BSD way
#if RUNNING_ON_SYSTEMV
Set things up in the SystemV way
#endif

Unix가 다른 구현(BSD, SystemV, 많은 공급업체 포크, 이후 Linux 및 기타 Unix 계열 시스템)으로 분기됨에 따라 이식 가능한 코드를 작성하려는 사람들이 특정 운영 체제에 묶여 있지 않은 코드를 작성하는 것이 점점 더 어려워졌습니다. 시스템 브랜드는 개발자에게 중요하지만 운영 체제에 의해 노출되는 기능을 기반으로 합니다. 이는 Unix 버전에 나중에 다른 운영 체제에서 채택될 "전송" 시스템 호출과 같은 새로운 기능이 도입되기 때문에 중요합니다. 많은 코드 검사 브랜드와 버전을 사용하는 대신 개발자는 기능별로 탐색하기 시작하여 코드는 다음과 같습니다.

#if HAVE_SEND
Use Send here
#else
Use something else
#endif

90년대에는 소스 코드 컴파일을 위한 대부분의 추가 정보 파일에서 개발자에게 config.h 파일을 편집하고 시스템에서 사용할 수 있는 적절한 기능을 주석 처리하거나 테스트된 모든 운영 체제 구성에 대해 표준 config.h 파일을 제공하도록 지시했습니다.

이 프로세스는 번거롭고 오류가 발생하기 쉬우므로 Autoconf가 필요합니다. Autoconf는 config.h의 수동 편집 프로세스를 운영 체제의 기능을 조사하는 도구로 대체하는 특수 매크로가 있는 쉘 명령으로 구성된 언어로 생각해야 합니다.

일반적으로 감지 코드를 configure.ac 파일에 작성한 다음 autoconf 명령을 실행합니다. 이 명령은 해당 파일을 사용한 실행 가능한 구성 명령으로 컴파일합니다.

따라서 실행하면 ./configure && make시스템에서 사용 가능한 기능을 감지한 다음 감지된 구성을 사용하여 실행 파일을 빌드합니다.

오픈소스 프로젝트가 소스코드 제어 시스템을 사용하여 시작할 때,configure.ac 파일을 체크인하는 것은 의미가 있지만, 컴파일(구성) 결과를 체크인하는 것은 의미가 없습니다. autogen.sh는 올바른 명령 매개변수를 사용하여 autoconf 컴파일러를 호출하는 작은 스크립트입니다.

--

Automake는 또한 커뮤니티의 기존 관행에서 성장했습니다. GNU 프로젝트는 Makefile의 일반적인 목표 세트를 표준화했습니다.

  • make all프로젝트를 빌드할 것이다
  • make clean컴파일된 모든 파일은 프로젝트에서 제거됩니다.
  • make install소프트웨어가 설치됩니다.
  • 배포할 소스 코드를 준비하고 그 결과가 완전한 소스 코드 패키지인지 확인하는 것과 같은 작업이 make dist될 것입니다.make distcheck
  • 등...

반복해서 반복되는 상용구가 많기 때문에 호환 가능한 makefile을 작성하는 것은 번거롭습니다. 따라서 Automake는 autoconf와 통합되어 "소스" Makefile(Makefile.am이라는 이름)을 Makefile로 처리한 다음 Autoconf에 공급하는 새로운 컴파일러입니다.

automake/autoconf 툴체인은 실제로 많은 다른 보조 도구를 사용하고 다른 특정 작업을 수행하기 위해 다른 구성 요소와 함께 이를 향상시킵니다. 이러한 명령을 순차적으로 실행하는 복잡성이 계속 증가함에 따라 즉시 실행할 수 있는 스크립트에 대한 필요성이 탄생했고, 이것이 autogen.sh가 탄생한 방식입니다.

내가 아는 한, Gnome은 이 도우미 스크립트 autogen.sh의 사용을 도입한 프로젝트입니다.

답변2

이 분야에는 Cmake와 GNU Autotools라는 두 개의 "대형 플레이어"가 있습니다.

  • GNU Autotools는 *nix에 중점을 두고 작업을 수행하는 GNU 방식입니다. 특정 구성을 생성하고 수행하려는 작업에 대한 파일을 생성하는 도구 세트를 제공하는 메타 빌드 시스템입니다. 이는 빌드 시스템을 직접 조작하지 않고도 코드를 더 많이 변경하는 데 도움이 될 수 있으며 다른 사람들이 *nix에서 설계되지 않은 방식으로 코드를 빌드하는 데 도움이 될 수 있습니다.

  • Cmake는 크로스 플랫폼 방식으로 작업을 수행합니다. Cmake 팀은 GCC, Visual Studio, XCode, Windows, OSX, Solaris, BSD, GNU/Linux 등을 포함한 다양한 방법으로 소프트웨어를 구축합니다. 코드베이스의 이식성에 깊은 관심을 갖고 있다면 이것이 올바른 선택입니다.

이미 언급했듯이 어떤 사람들은 스콘을 좋아하는 것 같습니다. Python에 익숙하다면 작업 환경에 더 많은 일관성을 제공할 수 있습니다.

Ruby에는 Rake라는 메타 빌드 시스템도 있는데, 이는 그 자체로 매우 멋지고 이미 Ruby에 익숙한 사람들에게 매우 편리합니다.

답변3

보루개인적인 경험은 없지만 가능한 대안입니다. Python으로도 구현되어 있는데, 빌드 환경에 따라 문제가 될 수 있습니다.

답변4

C#의 경우 프로젝트 파일에서 프로젝트를 빌드하는 xbuild(및 Windows의 경우 msbuild)를 사용할 수 있습니다.

관련 정보