맨위로가기

Autoconf

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

Autoconf는 1991년 데이비드 맥켄지가 자유 소프트웨어 재단의 작업을 지원하기 위해 시작한 소프트웨어로, 자유 및 오픈 소스 소프트웨어에서 널리 사용되는 빌드 구성 시스템이다. Autoconf는 기능 테스트를 통해 포팅에 접근하며, configure 스크립트는 새로운 시스템이나 관리자가 설정한 환경을 활용할 수 있도록 한다. Autoconf는 configure.ac 파일의 내용을 기반으로 configure 스크립트를 생성하고, 이 스크립트는 빌드 환경을 스캔하여 config.status 스크립트를 생성, Makefile.in을 Makefile로 변환한다. Autoconf는 m4 매크로 시스템을 사용하며, autoheader, autoscan, ifnames 등의 보조 프로그램과 함께 제공된다. 하지만 Autoconf는 구식 기술 사용, 복잡성, m4의 생소함, 호환성 문제 등으로 비판을 받으며, CMake, SCons와 같은 다른 빌드 시스템으로 전환하는 프로젝트도 있다.

더 읽어볼만한 페이지

  • 유닉스 - 유닉스 시간
    유닉스 시간은 1970년 1월 1일 00:00:00 UTC부터 경과된 초를 나타내는 시스템으로, 컴퓨터 시스템에서 시간 저장 및 처리에 널리 사용되며 32비트 정수 표현 시 2038년 문제를 야기할 수 있고 64비트 정수로 해결 가능하며, 다양한 시스템에서 타임스탬프로 활용되지만 윤초 처리 차이로 UTC 시간과 완벽히 일치하지는 않는다.
  • 유닉스 - 유닉스 계열
    유닉스 계열은 유닉스 운영체제의 특징과 설계를 공유하는 운영체제들을 지칭하며, 유전적, 상표, 기능적 유닉스로 분류되고 macOS는 상표 유닉스이자 유전적 유닉스에 해당하며 리눅스는 기능적 유닉스의 대표적인 예이다.
  • 컴파일러 - 바이너리 재컴파일러
  • 컴파일러 - 링커 (컴퓨팅)
    링커는 여러 모듈로 된 목적 파일을 결합해 실행 가능한 프로그램을 만들고, 정적/동적 링킹으로 라이브러리를 연결하며, 심볼 해결 및 재배치로 변수와 함수를 메모리 주소에 연결하는 소프트웨어 도구이다.
  • 자유 라이브러리 - Tk (소프트웨어)
    Tk는 Tcl 스크립팅 언어의 크로스 플랫폼 GUI 툴킷으로, 다양한 플랫폼 이식과 여러 프로그래밍 언어 바인딩을 지원하며 사용자 정의 가능한 위젯들을 제공한다.
  • 자유 라이브러리 - SQLite
    SQLite는 D. 리처드 히프가 설계한 서버리스 구조의 임베디드 SQL 데이터베이스 엔진으로, 별도의 DBMS 없이 프로그램에 통합되어 작동하며 전체 데이터베이스를 단일 파일로 저장하는 특징이 있고, 다양한 운영체제와 환경에서 널리 사용된다.
Autoconf - [IT 관련 정보]에 관한 문서
기본 정보
유형빌드 자동화 도구
라이선스GNU GPL
웹사이트Autoconf 공식 웹사이트
개발
개발자GNU 프로젝트
작성자데이비드 매켄지
최신 안정화 버전2.69
최신 안정화 버전 출시일2012년 4월 24일
프로그래밍 언어
운영 체제크로스 플랫폼

2. 역사

Autoconf는 1991년 여름 데이비드 매켄지(David Mackenzie)가 자유 소프트웨어 재단의 작업을 지원하기 위해 시작하였다. 그 뒤 여러 해 동안 다양한 제작자로부터 기능 개선을 제공받아 성장하였으며 자유, 오픈 소스 소프트웨어에서 가장 널리 쓰이는 빌드 구성 시스템이 되었다.[1]

3. 접근

Autoconf는 이 사용하는 Metaconfig 꾸러미와 비슷하다. X 윈도 시스템에서 사용된 imake 시스템은 이와 밀접한 관계가 있지만 시스템에 대한 관점은 다르다.[1]

Autoconf의 포팅 접근 방식은 기능을 테스트하는 것이지, 버전을 테스트하는 것이 아니다. 예를 들어, 썬OS 4의 네이티브 C 컴파일러는 ISO C를 지원하지 않았다. 그러나 사용자나 관리자가 ISO C 호환 컴파일러를 설치할 수 있었다. 순수한 버전을 기반으로 접근하면 ISO C 컴파일러의 존재를 파악하지 못하지만, 기능을 테스트하는 접근 방식은 사용자가 설치했던 ISO C 컴파일러를 발견할 수 있다.[1]

이러한 접근 방식은 다음과 같은 장점을 얻기 위한 것이다:[1]


  • configure 스크립트는 새로운 시스템이나 알 수 없는 시스템에서도 제대로 된 결과를 얻을 수 있다.
  • 관리자가 자신만의 컴퓨터 환경을 설정하고 configure 스크립트가 그 설정을 활용할 수 있게 도와준다.
  • 특정 기능의 지원 여부를 알아내기 위해 버전, 패치 번호 등 자세한 정보의 흔적을 유지할 필요가 없다.

4. 동작 방식

Autoconf와 Automake의 흐름도. "configure.ac"는 Autoconf 초기 버전에서는 "configure.in"으로 명명되었다는 점에 유의하십시오.


개발자는 "configure.ac"라는 파일에 GNU m4 언어로 된 일련의 지침을 작성하여 configure 스크립트의 원하는 동작을 지정한다. 일반적인 configure 스크립트 지침을 설명하기 위해 미리 정의된 m4 매크로 라이브러리를 사용할 수 있다. Autoconf는 "configure.ac"의 지침을 이식 가능한 configure 스크립트로 변환한다.[1]

빌드를 수행할 시스템에는 Autoconf가 설치되어 있을 필요가 없다. Autoconf는 일반적으로 소프트웨어와 함께 제공되는 configure 스크립트를 빌드하는 데만 필요하다.[1]

Autoconf는 특정 소스 코드 집합을 특성화하는 configure.ac 파일의 내용을 기반으로 configure 스크립트를 생성한다. configure 스크립트는 실행 시 빌드 환경을 스캔하고, 부속 config.status 스크립트를 생성하며, 이는 다시 다른 입력 파일, 가장 일반적으로 Makefile.in을 해당 빌드 환경에 적합한 출력 파일(Makefile)로 변환한다. 마지막으로, make 프로그램은 Makefile을 사용하여 소스 코드에서 실행 가능한 프로그램을 생성한다.[1]

Autotools의 복잡성은 소스 코드 집합이 빌드될 수 있는 다양한 상황을 반영한다.[1]

  • 소스 코드 파일이 변경된 경우 make를 다시 실행하는 것만으로 충분하며, 이는 변경의 영향을 받는 소스 코드 집합의 해당 부분만 다시 컴파일한다.[1]
  • .in 파일이 변경된 경우 config.statusmake를 다시 실행하는 것만으로 충분하다.[1]
  • 소스 코드 집합이 다른 컴퓨터로 복사된 경우 configure(config.status를 실행)와 make를 다시 실행하는 것만으로 충분하다. (이러한 이유로 Autotools를 사용하는 소스 코드는 일반적으로 configure가 생성하는 파일 없이 배포된다.)[1]
  • 소스 코드 집합이 더 근본적으로 변경된 경우 configure.ac.in 파일을 변경해야 하며, 모든 후속 단계도 따라야 한다.[1]


Autoconf는 파일을 처리하기 위해 m4 매크로 시스템의 GNU 구현을 사용한다.[1]

Autoconf에는 C 헤더 파일을 관리하는 데 사용되는 autoheader, Autoconf용 초기 입력 파일을 만들 수 있는 autoscan, 프로그램에서 사용되는 C 전처리기 식별자를 나열할 수 있는 ifnames 등 여러 보조 프로그램이 함께 제공된다.[1]

5. 비판

Autoconf는 구식 기술을 사용하고, 많은 레거시 제약이 있으며, `configure.ac` 스크립트 작성자에게 불필요하게 간단한 시나리오를 복잡하게 만든다는 비판이 있다.[2][3] 특히 Autoconf의 약점으로 자주 언급되는 것은 다음과 같다.


  • 사용된 아키텍처의 일반적인 복잡성. 대부분의 프로젝트에서 여러 번 반복 사용된다.[2][3]
  • 어떤 사람들은 Autoconf에 의해 생성된 'configure' 스크립트가 표준화 없이 수동으로 제어되는 명령줄 인터페이스만 제공한다고 생각한다.[5] 일부 개발자가 일반적인 관례를 존중하지 않는 것은 사실이지만, 그러한 관례는 존재하며 널리 사용된다.[4]
  • m4는 많은 개발자에게 생소하고 알려져 있지 않다. 개발자는 표준이 아닌 검사를 사용하여 Autoconf를 확장하려면 m4를 배워야 한다.[5][6]
  • 취약한 이전 버전 및 이후 버전 호환성은 래퍼 스크립트를 필요로 한다.[7]
  • Autoconf로 생성된 스크립트는 일반적으로 크고 다소 복잡하다. 광범위한 로깅을 생성하지만, 디버깅이 여전히 어려울 수 있다.


이러한 제약으로 인해, GNU 빌드 시스템을 사용하던 몇몇 프로젝트는 CMakeSCons와 같은 다른 빌드 시스템으로 전환했다.[2][8]

참조

[1] 웹사이트 Portable Shell https://www.gnu.org/[...] 2020-01-20
[2] 웹사이트 Why the KDE project switched to CMake -- and how https://lwn.net/Arti[...] 2006-06-21
[3] 논문 A Generation Lost in the Bazaar 2012-08-15
[4] 웹사이트 GNU Coding Standards https://www.gnu.org/[...]
[5] 웹사이트 Stop the autoconf insanity! Why we need a new build system http://freshmeat.net[...] 2003-06-21
[6] 웹사이트 Did you call them ''autocrap'' tools? https://varnish-cach[...] 2017-08-16
[7] 웹사이트 why i still use autoconf 2.13 http://invisible-isl[...]
[8] 웹사이트 Blender.org - Build systems http://www.blender.o[...] 2009-06-10



본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com