GNU 자동 풀

GNU Autotools
GNU 로고

GNU 오토툴스(Autotools)는 GNU 빌드 시스템이라고도 알려져 있으며, 소스 코드 패키지를 많은 유닉스급 시스템에서 휴대할 수 있도록 지원하기 위해 고안된 프로그래밍 도구 모음입니다.

소프트웨어 프로그램을 휴대용으로 만드는 것은 어려울 수 있다: C 컴파일러는 시스템마다 다르다; 일부 시스템에서는 특정 라이브러리 기능이 누락되어 있다; 헤더 파일의 이름은 다를 수 있다.이를 처리하는 한 가지 방법은 전처리기 지시문을 통해 선택된 코드 블록으로 조건부 코드를 작성하는 것이다.#ifdef); 그러나 다양한 빌드 환경으로 인해 이 접근 방식은 빠르게 관리할 수 없게 된다.오토툴은 이 문제를 보다 관리적으로 다루기 위해 고안되었다.

오토툴스는 GNU 툴체인의 일부로 많은 무료 소프트웨어와 오픈 소스 패키지에 널리 사용된다.그것의 구성요소 도구는 GNU General Public License에 따라 라이센스가 부여된 무료 소프트웨어로, 독점 소프트웨어 사용을 허용하는 특별한 라이센스 예외가[1][2] 있다.

GNU 빌드 시스템은 2단계 과정을 통해 많은 프로그램을 만들 수 있게 한다:[3] 구성 후 제조.

구성 요소들

오토콘 및 오토메이크의 흐름도

Autotools는 GNU 유틸리티 프로그램 Autoconf, Automake, Libtool로 구성된다.[4]그 외에 자주 사용하는 관련 도구로는 GNU의 make program, GNU gettext, pkg-config, GCC라고도 불리는 GNU 컴파일러 모음 등이 있다.

GNU 오토콘프

Autoconf에서 생성되는 데이터:configure의 내용에 기초하여 대본화하다configure.ac소스 코드의 특정 본문을 특징짓는 파일.그configure스크립트, 실행 시 빌드 환경을 검색하고 하위 시스템을 생성config.status다시 다른 입력 파일을 변환하고 가장 일반적으로 변환하는 스크립트Makefile.in출력 파일로 (Makefile() 해당 빌드 환경에 적합한.마침내, 더make프로그램 사용Makefile소스 코드에서 실행 가능한 프로그램을 생성하십시오.

Autotools의 복잡성은 소스 코드 본체가 구축될 수 있는 다양한 상황을 반영한다.

  • 소스 코드 파일이 변경되면 재실행할 수 있음make는 변경의 영향을 받는 소스 코드의 본문 일부만 다시 컴파일한다.
  • 만약.in파일이 변경되어 다시 실행하기에 충분함config.status그리고make.
  • 소스 코드의 본문을 다른 컴퓨터에 복사한 경우, 다시 실행하기에 충분하다.configure(그것은 계속된다.config.status) 및make. (이 때문에 Autotools를 사용하는 소스 코드는 일반적으로 다음 파일 없이 배포된다.configure생성한다.)
  • 소스 코드의 본문이 좀 더 근본적으로 바뀐다면,configure.ac그리고.in파일을 변경해야 하며 모든 후속 단계도 따라야 한다.

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

Autoconf는 다음과 같은 몇 가지 보조 프로그램과 함께 제공된다.autoheader Cheader 파일 관리를 돕는 데 사용된다.autoscan, Autoconf에 대한 초기 입력 파일을 생성할 수 있는 기능 및ifnames프로그램에 사용된 C 사전 프로세서 식별자를 나열할 수 있는 .

GNU 오토메이크

오토메이크가 휴대용 컴퓨터 제작에 도움이 됨Makefiles, 제조 유틸리티로 차례대로 처리된다.그것은 그 의견을 다음과 같이 받아들인다.Makefile.am로 바꾸다.Makefile.in, 파일을 생성하기 위해 구성 스크립트에서 사용됨Makefile생산량또한 자동 종속성 추적을 수행하며, 소스 파일이 컴파일될 때마다 종속성 목록(예: C 헤더 파일)이 기록된다.나중에 언제든지 만들기를 실행하고 종속성이 변경된 것으로 나타나면 종속 파일이 다시 작성될 것이다.

GNU Libtool

Libtool은 다양한 Unix 유사 운영 체제에서 정적 및 동적 라이브러리 생성을 관리하는 데 도움이 된다.Libtool은 라이브러리 생성 프로세스를 추상화하여 다양한 시스템 간의 차이점(예: Linux 시스템 vs)을 숨김으로써 이를 실현한다.Solaris).

사용법

오토툴스는 소프트웨어 개발자들이 크로스 플랫폼 소프트웨어를 작성하고 소프트웨어를 직접 만들고자 하는 사용자들에게 소스 코드 형태로 제공하는 것을 포함하여 훨씬 더 넓은 사용자 커뮤니티에 사용할 수 있도록 돕는다.대부분의 경우 사용자는 제공된 제품을 간단히 실행하십시오.configure 스크립트(Bourne-compatibleshell의 존재 외에 종속성이 없는 스크립트) 및make프로그램을 [5]짜다그들은 오토툴스 자체를 컴퓨터에 설치할 필요가 없다.

빌드 머신에서 기본 프로그램을 구축하는 데 사용할 수 있고 다른 아키텍처와의 교차 컴파일에도 사용할 수 있다.[6]

Linux 또는 기타 유닉스 유사 빌드 시스템에서 윈도우즈 호스트에서 실행되는 교차 컴파일 소프트웨어도 MinGW를 사용하여 가능하지만, Bourne 셸 스크립트를 자체적으로 실행할 수 없는 운영 체제(예: 마이크로소프트 윈도우즈 시스템 제품군)에서는 기본 컴파일이 바람직한 경우가 많다.이것은 윈도우 운영 체제에서 그러한 소프트웨어를 만드는 것을 본 셸을 표준 구성요소로 제공하는 유닉스 같은 시스템보다 약간 어렵게 만든다.그러나 윈도우즈 위에 Cygwin 또는 MSYS 시스템을 설치하여 Unix와 유사한 호환성 계층을 제공할 수 있어 구성 스크립트를 실행할 수 있다.또한 Cygwin은 GNU Compiler Collection, GNU make 및 Windows 내에서 거의 완전한 유닉스 같은 시스템을 제공하는 기타 소프트웨어를 제공하며 MSYS는 GNU make와 GCC의 MinGW 버전과 함께 작동하도록 설계된 기타 도구도 제공한다.

개발자가 최종 사용자를 위해 구성 스크립트를 제공해야 하지만, 때때로 사용자는 구성 스크립트 자체를 다시 생성하기를 원할 수 있다.사용자가 소스 코드 자체를 수정하려면 이러한 작업이 필요할 수 있다.이러한 사용자는 Autotools를 설치하고 Autoreconf와 같은 구성요소를 사용해야 한다.

오토콘프 생성configure다양한 라이브러리, 헤더 파일 및 언어 기능이 있는지 테스트하기 위해 C 컴파일러와 같은 프로그램을 여러 번 실행하기 때문에 느릴 수 있다.이것은 특히 Cygwin에 영향을 미치는데, 이것은 네이티브 포크 시스템 호출이 없기 때문에 리눅스보다 훨씬 느리게 구성 스크립트를 실행할 수 있다.[7]

비판

ACM 큐의 칼럼에서 FreeBSD 개발업체인 Poul-Henning Kamp는 GNU 빌드 시스템을 다음과 같이 비판했다.[8]

구성 스크립트는 사용자가 libtool을 수동으로 구성하는 데 부담을 갖지 않도록 약 200개의 자동 테스트를 수행한다는 생각이다.이것은 1980년대에 등장했을 때 이미 많은 비난을 받았던 끔찍하게 나쁜 생각인데, 그것은 소스코드가 처음부터 휴대성의 질을 가지기 보다는 구성 스크립트의 베니어 뒤에 있는 휴대용인 척 할 수 있게 해주었기 때문이다.그 구성 아이디어가 살아남았다는 것은 희한한 일이다.

Kamp는 빌드 시스템의 역사를 1980년대 유닉스 변종의 다양성에 내재된 이식성 문제에서 밑그림을 그리고 있으며, 이러한 빌드 시스템이 존재해야 하는 필요성을 강조한다.

libtool에 대한 구성의 31,085 라인은 여전히 <sys/stat> 여부를 확인한다.h>와 <stdlib>.h>가 존재하는데, 그 메모리가 부족했던 유닉스호는 libtool을 실행하기에 충분한 메모리와 16MB의 소스 코드에 충분한 크기의 디스크를 가지고 있지 않았다.

비판에 대한 대응

오토툴스 비판론자들은 종종 사용자들에게 더 큰 단순성을 제공하는 대안을 옹호하지만, 일부 사람들은 이것이 반드시 좋은 것은 아니라고 주장해왔다.Autotools 2판의 저자[9]: GNU Autoconf, Automake, Libtool에 대한 실무자 가이드(John Calcote)는 다음과 같이 밝혔다.[10]

오토툴은 실제로 다른 어떤 빌드 툴보다 더 투명하다.이 모든 다른 도구들(케이크, 메이븐 등)은 사용자를 빌드 프로세스의 기본 세부사항으로부터 격리시키기 때문에 훨씬 더 단순하다고 주장하는데, 이러한 도구의 주요 장애는 바로 이러한 절연으로 사용자가 고유한 프로젝트별 빌드 목표를 달성하는 데 필요한 변경을 할 수 없게 한다는 것이다.

cmake, maven, gradle 또는 그 무엇의 이런 측면에 대해 좋은 말밖에 할 것이 없는 사람은 누구나 채무 불이행으로부터 충분히 멀리 이동하도록 요구하는 프로젝트에 대해 간단히 일하지 않았다.나는 그것들을 모두 사용해왔고, 내가 원하는 것을 제외한 어떤 "모두 실행" 도구 기능의 단점을 어떻게 해결할지를 결정하기 위해 몇 시간을 허탈감 속에서 보냈다.이것은 단순히 오토툴스와의 문제가 아니다.이 스레드에서 앞서 언급한 바와 같이 셸 스크립트를 configure.ac 파일에 떨어뜨려 Makefile.am 파일로 만들 수 있다.그것이 바로 투명성의 정의다.존재하는 다른 어떤 도구도 이 정도의 유연성을 허용하지 않는다.

참고 항목

참조

  1. ^ "Savannah Git Hosting - autoconf.git/blob - COPYING.EXCEPTION". Git.savannah.gnu.org. Archived from the original on 2011-07-21. Retrieved 2016-04-01.
  2. ^ "libtool.git - GNU Libtool". Git.savannah.gnu.org. 2005-01-08. Retrieved 2016-04-01.
  3. ^ "The GNU configure and build system - Introduction". Airs.com. 1998-07-01. Retrieved 2016-04-01.
  4. ^ "Learning the GNU development tools". Autotoolset.sourceforge.net. Retrieved 2016-04-01.
  5. ^ "automake: GNU Build System". Gnu.org. 2014-12-31. Retrieved 2016-04-01.
  6. ^ "Cross Compilation with GNU Autotools". Archived from the original on October 13, 2008. Retrieved September 24, 2008.
  7. ^ "Robert Ögren - Slow shell script execution on Cygwin". Cygwin.com. Retrieved 2016-04-01.
  8. ^ Kamp, Poul-Henning (2012). "A Generation Lost in the Bazaar". ACM Queue. 10 (8).
  9. ^ "Autotools, 2nd Edition by John Calcote Penguin Random House Canada". Retrieved January 22, 2021.
  10. ^ "Re: Future plans for Autotools". Retrieved January 22, 2021.

외부 링크