자동 설정

Autoconf
Autoconfig와 혼동하지 마십시오.
사용자 액세스레벨에 대해서는 WP:AUTOCONF.
자동 설정
Heckert GNU white.svg
원저작자데이비드 매켄지
개발자GNU 프로젝트
초기 릴리즈1991
안정된 릴리스
2021년 1월 28일 2.71; 18개월 전(2021-01-28)[1]
저장소
기입처펄
운영 체제크로스 플랫폼
유형프로그래밍 도구
면허증.GNU GPL
웹 사이트www.gnu.org/software/autoconf/

GNU Autoconf는 Bourne 쉘을 사용할 수 있는 컴퓨터 시스템에서 소프트웨어를 빌드, 설치 및 패키징하기 위한 구성 스크립트를 작성하는 도구입니다.

Autoconf는 사용되는 프로그래밍 언어에 의존하지 않지만 C, C++, Fortran, Fortran 77, Erlang 또는 Objective-C를 사용하는 프로젝트에서 자주 사용됩니다.

설정 스크립트는 특정 타깃시스템에 설치할 소프트웨어 패키지를 설정합니다.타깃 시스템에서 일련의 테스트를 실행한 후 구성 스크립트는 템플릿에서 헤더 파일 및 make 파일을 생성하여 타깃시스템용 소프트웨어 패키지를 커스터마이즈합니다.Autoconf는 Automake 및 Libtool과 함께 GNU 빌드 시스템을 형성합니다.GNU 빌드 시스템은 오토헤더와 같은 다른 툴로 구성됩니다.

사용방법 개요

autoconf 및 automake 흐름도.autoconf 이전 버전에서 "configure.ac"은 "configure.in"로 명명되었습니다.

개발자는 "configure.ac"이라는 파일에 GNU m4 언어로 된 명령 목록을 작성하여 구성 스크립트의 원하는 동작을 지정합니다.사전 정의된 m4 매크로 라이브러리를 사용하여 일반적인 스크립트 구성 절차를 설명할 수 있습니다.autoconf 는, 「configure.ac」의 순서를 포터블 설정 스크립트로 변환합니다.빌드를 실행하는 시스템에는 autoconf를 설치할 필요가 없습니다.autoconf는 보통 소프트웨어와 함께 제공되는 설정 스크립트를 빌드하기 위해서만 필요합니다.

역사

Autoconf는 1991년 여름 David Mackenzie에 의해 Free Software Foundation에서 그의 업무를 지원하기 위해 시작되었습니다.그 후 몇 년 동안 다양한 저자의 향상된 기능을 포함하게 되었고, 휴대용 자유 소프트웨어 또는 오픈 소스 소프트웨어를 작성하기 위해 가장 널리 사용되는 빌드 구성 시스템이 되었습니다.

접근

Autoconf는 Perl에서 사용되는 Metaconfig 패키지와 유사합니다.이전에 X Window System(X11R6.9까지)에서 사용되었던 imake 시스템은 밀접하게 관련되어 있지만 철학은 다릅니다.

휴대성에 대한 Autoconf 접근법은 버전이 아닌 기능을 테스트하는 것입니다.예를 들어 SunOS 4의 네이티브 C 컴파일러는 ISO C를 지원하지 않지만 사용자 또는 관리자가 ISO C 호환 컴파일러를 설치했을 수 있습니다.순수 버전 기반 접근법으로는 ISO C 컴파일러의 존재를 검출할 수 없지만 기능 테스트 접근법으로는 사용자가 설치한 ISO C 컴파일러를 검출할 수 있습니다.이 접근방식의 근거는 다음과 같은 이점을 얻기 위한 것입니다.

  • 구성 스크립트는 새로운 시스템 또는 알려지지 않은 시스템에서 적절한 결과를 얻을 수 있습니다.
  • 관리자는 머신을 커스터마이즈하여 구성 스크립트가 커스터마이즈된 기능을 활용할 수 있습니다.
  • 특정 기능이 지원되는지 여부를 파악하기 위해 버전, 패치 번호 등의 세부 정보를 추적할 필요가 없습니다.

Autoconf는 많은 POSIX 쉘 구조의 오래된 셸 및 버그에 대한 이식 불가능성에 대한 광범위한 문서를 제공합니다.또, 셸 구문을 [2]매크로 베이스로 대체한 M4SH도 제공하고 있습니다.

비판

Autoconf 에서는 오래된 테크놀로지를 사용하고 있어 레거시 제한이 많아 configure.ac 스크립트 작성자에게 불필요하게 간단한 시나리오를 복잡하게 하고 있다는 지적이 있습니다.특히 Autoconf의 약점은 다음과 같습니다.

  • 사용된 아키텍처는 일반적으로 복잡하지만 대부분의 프로젝트에서는 여러 [3][4]번 반복됩니다.
  • 생성된 'configure'는 Bourne 쉘로 작성되므로 Makefile 생성 속도가 느립니다.
  • autoconf에 의해 생성된 'configure' 스크립트는 [5]표준화 없이 수동 방식의 명령줄 인터페이스만 제공한다고 생각하는 사람도 있습니다.일부 개발자가 일반적인 규약을 존중하지 않는 것은 사실이지만, 그러한 규약은 존재하며 널리 [6]사용되고 있다.
  • M4는 특이하고 많은 개발자들에게 알려져 있지 않습니다.개발자는 비표준 [5][7]체크를 사용하여 autoconf를 확장하려면 이 방법을 익혀야 합니다.
  • 하위 및 상위 호환성이 약하려면 래퍼 [8]스크립트가 필요합니다.
  • autoconf 생성 스크립트는 보통 크고 복잡합니다.광범위한 로깅이 생성되지만 디버깅은 여전히 어려울 수 있습니다.

이러한 제한으로 인해 GNU 빌드 시스템을 사용한 몇몇 프로젝트들은 CMake나 [3][9]SCon과 같은 다른 빌드 시스템으로 전환되었습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "autoconf-2.71 released [stable]". autoconf Archives. Retrieved 2021-01-29.
  2. ^ "Portable Shell". Autoconf. Retrieved 20 January 2020.
  3. ^ a b Neundorf, Alexander (2006-06-21). "Why the KDE project switched to CMake -- and how".
  4. ^ Kamp, Poul-Henning (2012-08-15). "A Generation Lost in the Bazaar". ACM Queue. 10 (8): 20–23. doi:10.1145/2346916.2349257. S2CID 11656592.
  5. ^ a b McCall, Andrew (2003-06-21). "Stop the autoconf insanity! Why we need a new build system".
  6. ^ "GNU Coding Standards".
  7. ^ Kamp, Poul-Henning (2010-04-20). "Did you call them autocrap tools?". Archived from the original on 2017-09-11. Retrieved 2017-08-16.
  8. ^ Dickey, Thomas. "why i still use autoconf 2.13".
  9. ^ "Archived copy". Archived from the original on 2008-12-02. Retrieved 2009-06-10.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)

외부 링크