☰

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 버전에는 "send" 시스템 호출과 같은 새로운 기능이 도입되고 나중에 다른 운영 체제에서도 이를 채택하게 되므로 이는 중요합니다. 브랜드와 버전을 확인하는 코드 스파게티를 사용하는 대신 개발자는 기능별로 조사하기 시작하여 코드는 다음과 같습니다.

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

90년대 개발자들이 소스 코드를 컴파일하기 위한 대부분의 README 파일은 config.h 파일을 편집하고 시스템에서 사용할 수 있는 적절한 기능을 주석 처리하거나 테스트된 각 운영 체제 구성에 대한 표준 config.h 파일을 제공했습니다.

이 프로세스는 번거롭고 오류가 발생하기 쉬웠으며 이것이 Autoconf의 탄생 방식이었습니다. Autoconf는 config.h의 인간 편집 프로세스를 운영 체제의 기능을 조사하는 도구로 대체할 수 있는 특수 매크로가 있는 쉘 명령으로 구성된 언어로 생각해야 합니다.

일반적으로 구성 파일에 검색 코드를 작성한 다음 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는 작업을 수행하는 GNU 방식이며 *nix에 상당히 초점을 맞추고 있습니다. 이는 특정 구성을 생성하고 수행하려는 작업에 대한 파일을 만드는 도구 세트를 제공하는 일종의 메타 빌드 시스템입니다. 이는 빌드 시스템을 직접 조작하지 않고도 코드를 더 많이 변경하는 데 도움이 되며 다른 사람들이 *nix에서 설계하지 않은 방식으로 코드를 빌드하는 데 도움이 됩니다.

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

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

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

답변3

스콘개인적인 경험은 없지만 가능한 대체품 중 하나입니다. 또한 Python으로 구현되는데, 이는 빌드 환경에 따라 문제가 될 수 있습니다.

답변4

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

관련 정보