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

때로는 소스에서 앱을 컴파일하고 다음 중 하나를 사용하고 있습니다.

./configure
make
sudo make install

그러나 최근 ./autogen.sh에는 구성 및 생성 스크립트를 생성하고 실행하는 스크립트 가 나왔습니다 .

C / C ++ / C # (mono) 컴파일을 간소화하는 다른 방법은 무엇입니까? 조금 오래된 것 같습니다. 새로운 도구가 있습니까? 선택이 주어지면 어느 것을 사용해야합니까?

Autoconf와 Automake는 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와 유사한 시스템)으로 갈수록 특정 브랜드의 운영 체제에 의존하지 않는 코드를 작성하기 위해 이식 가능한 코드를 작성하려는 개발자에게 중요해졌습니다. 운영 체제에서 제공하는 기능 이것은 유닉스 버전이 새로운 기능, 예를 들어 "보내기"시스템 호출을 도입하고 나중에 다른 운영 체제에서도 채택하기 때문에 중요합니다. 브랜드와 버전을 확인하는 코드 스파게티를 사용하는 대신 개발자는 기능별로 프로빙을 시작하여 코드가 다음과 같이되었습니다.

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

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

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

일반적으로 프로빙 코드를 configure.ac 파일에 작성한 다음 autoconf 명령을 실행하면이 파일을 사용 된 실행 가능한 configure 명령으로 컴파일 할 수 있습니다.

따라서 실행할 때 ./configure && make시스템에서 사용 가능한 기능을 조사한 다음 감지 된 구성으로 실행 파일을 빌드했습니다.

오픈 소스 프로젝트가 소스 코드 제어 시스템을 사용하여 시작되면 configure.ac 파일을 체크인하는 것이 좋으나 컴파일 결과 (configure)는 아닙니다. autogen.sh는 적절한 명령 인수로 autoconf 컴파일러를 호출하는 작은 스크립트 일뿐입니다.

-

Automake는 커뮤니티의 기존 관행에서도 성장했습니다. GNU 프로젝트는 Makefile에 대한 규칙적인 대상 세트를 표준화했습니다.

• make all 프로젝트를 만들 것입니다
• make clean 프로젝트에서 컴파일 된 모든 파일을 제거합니다.
• make install 소프트웨어를 설치합니다
• 같은 것들 make dist과 make distcheck배포를 위해 소스를 준비하고 결과가 완전한 소스 코드 패키지되었는지 확인 것
• 등등...

계속해서 반복되는 상용구가 많기 때문에 호환되는 메이크 파일을 작성하는 것은 부담이되었습니다. 따라서 Automake는 autoconf와 통합되어 "source"Makefile (Makefile.am)을 Makefile로 처리 한 다음 Autoconf에 공급할 수있는 새로운 컴파일러였습니다.

automake / autoconf 툴체인은 실제로 여러 가지 다른 도우미 도구를 사용하며 다른 특정 작업을 위해 다른 구성 요소에 의해 보강됩니다. 이러한 명령을 순서대로 실행하는 복잡성이 증가함에 따라 바로 실행할 수있는 스크립트가 필요해졌으며, 여기서 autogen.sh가 시작되었습니다.

내가 아는 한, 그놈은이 헬퍼 스크립트 autogen.sh의 사용을 소개 한 프로젝트였습니다.

이 영역에는 두 개의 "빅 플레이어"가 있습니다. Cmake 및 GNU Autotools.

• GNU Autotools는 GNU 작업 방식이며 * nix에 상당히 집중되어 있습니다. 일종의 메타 빌드 시스템으로 특정 구성을 생성하고 수행하려는 작업에 대한 파일을 만드는 도구 세트를 제공합니다. 이를 통해 빌드 시스템을 직접 조작하지 않고도 코드를 더 많이 변경할 수 있으며 * nix에서 설계하지 않은 방식으로 다른 사람들이 코드를 작성할 수 있습니다.

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

언급했듯이 일부 사람들은 스콘을 좋아하는 것으로 보입니다. 파이썬에 익숙하다면 작업 환경에서 일관성이 향상 될 수 있습니다.

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

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

C # / Mono를 사용하는 경우 msbuild (MonoDevelop 및 Visual Studio에서 사용되는 .sln / .csproj 파일)를 사용하여 전체 빌드 프로세스를 관리 할 수 ​​있습니다.

그런 다음 MonoDevelop에서 빌드하거나 xbuild선호하는 터미널에서 명령을 실행할 수 있습니다 (Mono> = 2.6에서 가장 잘 작동 함). MonoDevelop는 msbuild 파일을 처리하므로 MonoDevelop UI가 할 수있는 것 이상의 작업을 조정하지 않는 한 편집 할 필요가 없기 때문에이 작업은 매우 쉽고 작업이 거의 필요하지 않습니다.

msbuild에 의존하는 사람들이 프로젝트의 설치를 처리하는 방법에 익숙하지 않지만 항상 요청할 수 있습니다. ;-)

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