맨위로가기

GNU 빌드 시스템

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

1. 개요

GNU 빌드 시스템은 소프트웨어의 이식성과 빌드 자동화를 지원하는 도구 모음으로, Autoconf, Automake, Libtool 등으로 구성된다. Autoconf는 configure 스크립트를 생성하여 빌드 환경을 설정하고, Automake는 Makefile.in 파일을 자동으로 생성한다. Libtool은 라이브러리 관리를 돕는다. Autotools는 크로스 플랫폼 빌드를 지원하며, configure 스크립트의 옵션을 통해 설치 경로, 다른 패키지 사용 여부 등을 설정할 수 있다. GNU 빌드 시스템은 투명성과 유연성을 제공하는 장점이 있지만, 복잡하다는 비판도 존재하며, CMake와 같은 대안이 사용되기도 한다.

더 읽어볼만한 페이지

  • 컴파일 도구 - Libtool
    Libtool은 다양한 유닉스 계열 운영 체제에서 정적 및 동적 라이브러리 생성을 관리하고, 운영 체제별 차이로 인한 소프트웨어 이식 문제를 해결하기 위해 GNU 빌드 시스템에서 사용되는 도구이다.
  • 컴파일 도구 - MSBuild
    MSBuild는 마이크로소프트에서 개발한 빌드 자동화 도구로서, 프로젝트 파일에 기술된 대상을 실행하여 빌드 과정을 자동화하며, Team Foundation 빌드와 연동하여 팀 빌드 환경을 구성하는 데 사용된다.
  • 빌드 자동화 - MSBuild
    MSBuild는 마이크로소프트에서 개발한 빌드 자동화 도구로서, 프로젝트 파일에 기술된 대상을 실행하여 빌드 과정을 자동화하며, Team Foundation 빌드와 연동하여 팀 빌드 환경을 구성하는 데 사용된다.
  • 빌드 자동화 - Gradle
    Gradle은 빌드 프로세스를 자동화하는 오픈 소스 시스템으로, Groovy를 기반으로 하며 짧은 설정 파일로 빌드 단계를 설명하고 플러그인을 통해 기능을 확장하며 Ant와 통합된다.
  • 유닉스 - 유닉스 시간
    유닉스 시간은 1970년 1월 1일 00:00:00 UTC부터 경과된 초를 나타내는 시스템으로, 컴퓨터 시스템에서 시간 저장 및 처리에 널리 사용되며 32비트 정수 표현 시 2038년 문제를 야기할 수 있고 64비트 정수로 해결 가능하며, 다양한 시스템에서 타임스탬프로 활용되지만 윤초 처리 차이로 UTC 시간과 완벽히 일치하지는 않는다.
  • 유닉스 - 유닉스 계열
    유닉스 계열은 유닉스 운영체제의 특징과 설계를 공유하는 운영체제들을 지칭하며, 유전적, 상표, 기능적 유닉스로 분류되고 macOS는 상표 유닉스이자 유전적 유닉스에 해당하며 리눅스는 기능적 유닉스의 대표적인 예이다.
GNU 빌드 시스템 - [IT 관련 정보]에 관한 문서
GNU Autotools 정보
종류소프트웨어 빌드 도구 모음
개발자커뮤니티
운영 체제크로스 플랫폼
플랫폼GNU 및 기타
포함GNU 운영 체제
프로그래밍 언어M4 (컴퓨터 언어), C
라이선스GNU 일반 공중 사용 허가서 버전 2
웹사이트GNU 소프트웨어

2. 구성 요소

GNU 빌드 시스템의 주요 구성 요소는 다음과 같다.


  • GNU Autoconf
  • GNU Automake
  • GNU Libtool
  • Gnulib


Autotools 도구의 흐름도


소프트웨어 프로그램을 여러 시스템에 맞게 만드는 것은 어려울 수 있다. 시스템마다 컴파일러가 다르고, 일부 시스템에는 특정 라이브러리 함수가 없을 수 있다. 컴파일러 파일(예: C 헤더)의 이름이 다를 수도 있고, 공유 라이브러리는 다른 방식으로 컴파일되고 설치될 수 있다. 이러한 플랫폼 차이를 처리하는 한 가지 방법은 조건부로 컴파일되는 코드(예: `#ifdef` 사용)를 작성하는 것이지만, 다양한 빌드 환경으로 인해 이 방법은 금방 관리하기 어려워진다. 오토툴은 이러한 문제를 보다 관리하기 쉽게 해결하도록 설계되었다.

오토툴은 GNU 유틸리티인 Autoconf, Automake, Libtool로 구성된다.[3] 이 외에도 GNU make, GNU gettext, pkg-config, GNU 컴파일러 모음(GCC) 등이 관련 도구로 꼽힌다.

Autotools는 비교적 넓은 사용자 커뮤니티를 가지고 있으며, 크로스 플랫폼 소프트웨어를 공유하는 데 도움을 준다. 사용자가 직접 소프트웨어를 빌드할 수 있도록 비교적 강력한 크로스 플랫폼 빌드 지원을 제공하여 소스 코드 공유를 용이하게 한다. 일반적으로 소스 코드는 스크립트와 함께 배포되며, 이 스크립트의 이름은 'configure'이고 본 호환 셸 외에는 종속성이 없다. Autotools를 사용할 필요는 없지만, 사용자는 `configure`를 실행하여 'Makefile'을 포함한 다양한 파일을 생성하고, `make`를 실행하여 이 파일을 사용할 수 있다.[4][5]

Autotools는 빌드 머신에서 네이티브 프로그램을 빌드하는 데 사용될 수 있으며, 다른 아키텍처로의 크로스 컴파일에도 사용될 수 있다.[6]

Linux 또는 기타 Unix 계열 빌드 시스템에서 Windows에서 실행할 소프트웨어를 크로스 컴파일하는 것도 MinGW를 사용하여 가능하다. 하지만 Bourne 셸 스크립트를 자체적으로 실행할 수 없는 운영 체제(예: 마이크로소프트 윈도우 시스템)에서는 네이티브 컴파일이 종종 바람직하다. Cygwin 또는 MSYS 시스템을 Windows에 설치하여 Unix 계열 호환성 계층을 제공하여 configure 스크립트가 실행되도록 할 수 있다. Cygwin은 GNU 컴파일러 모음, GNU make 및 Windows 내에서 거의 완전한 Unix 계열 시스템을 제공하는 기타 소프트웨어를 제공한다. MSYS는 MinGW 버전의 GCC와 함께 작동하도록 설계된 GNU make 및 기타 도구를 제공한다.

autoconf로 생성된 configure 스크립트는 C 컴파일러와 같은 프로그램을 여러 번 실행하여 다양한 라이브러리, 헤더 파일 및 언어 기능이 있는지 테스트하기 때문에 느릴 수 있다. 특히 Cygwin은 네이티브 fork 시스템 호출이 없기 때문에 Linux보다 configure 스크립트를 상당히 느리게 실행할 수 있다.[7]

2. 1. GNU Autoconf

'''Autoconf''' (autoconf)는 configuration 스크립트를 자동 생성하는 도구이다.[12]

빌드 환경 자동 구축을 수행하는 configuration 스크립트 (configure)는 때때로 수천 줄에 달하는 거대한 스크립트가 된다. 이를 수동으로 작성하고 유지하는 것은 시간 낭비이며 버그의 온상이 된다. Autoconf는 이 configure 생성을 자동화하는 도구이다.[12]

Autoconf는 configure.ac를 입력으로 받아 configure를 출력한다.[13] 사용자가 이 configure를 실행하면 빌드 환경이 구축된다. autoconf는 데이비드 매켄지가 자유 소프트웨어 재단에서의 작업을 위해 1991년 여름부터 개발을 시작했다. 그 후, 다양한 사람들에 의해 개선되어 오픈 소스 커뮤니티에서 가장 많이 사용되는 도구 중 하나가 되었다.

autoconf는 Perl에서 사용되는 Metaconfig와 유사하다. 과거(X11R6.9까지) X Window System에서 사용되었던 imake|imake영어와도 밀접하게 관련되어 있지만, 설계 사상이 다르다.

autoconf는 이식성 평가를 버전이 아닌 기능 기반으로 수행한다. 예를 들어 SunOS 4의 C 컴파일러는 ISO C를 지원하지 않는다. 그러나 사용자는 ISO C 호환 컴파일러를 설치할 수도 있다. 버전만으로는 ISO C 컴파일러의 존재를 감지할 수 없지만, 기능 기반 방식에서는 사용자가 설치한 ISO C 컴파일러를 발견할 수 있다. 그 외에도 다음과 같은 이점이 있다.

  • 패키지 개발 후에 등장한 새로운(알려지지 않은) 시스템에서도 잘 작동한다.
  • 사용자 정의 환경에도 잘 대응할 수 있다.
  • 버전이나 패치 등을 상세하게 파악해둘 필요가 없다.


m4 언어의 매크로와 셸 스크립트 조각으로 작성된 입력 파일 configure.ac (구 버전에서는 configure.in)을, autoconf가 m4를 사용하여 치환하여 configure를 얻는다. 최종 출력인 configure는 Bourne 셸용 셸 스크립트이며, 수백 행에서 수천 행의 길이를 갖는다.

다음은 간단한 configure.ac의 예시이다.

```text

AC_INIT(hello, 1.9, address) # 필수 설정

AC_CONFIG_SRCDIR([hello.c])

# 이 패키지에서는 hoge를 사용할 수 있다. configure에 --with-hoge가 추가된다.

# (실제로는, 이 다음에 사용자가 --with-hoge=yes로 설정했을 때의 동작 정의를 기술해야 한다.)

AC_ARG_WITH(hoge, [Use hoge])

AC_PROG_CC # C 컴파일러 설정. configure가 환경 변수 CC를 사용한다.

AC_OUTPUT([Makefile]) # Makefile.in을 템플릿으로 하여 Makefile을 생성

```

출력되는 configure는 매우 길기 때문에 게재하지 않는다. 이 경우 일반적인 옵션은 지원된다. 사용자의 요구에 따라 hoge를 사용할지 여부를 결정한다. 또한, C 컴파일러를 찾아 실행 방법을 확인하고, 그 결과 얻어진 명령 이름, 필요한 옵션 등을 Makefile에 출력한다.

2. 2. GNU Automake

'''GNU 오토메이크'''(automake)는 Makefile.in 파일을 자동으로 생성하는 도구이다.[14]

오토메이크는 프로그램과 소스 코드의 관계 등이 기술된 Makefile.am 파일을 입력으로 하여 Makefile.in을 출력한다.

HelloWorld 프로그램 예시는 다음과 같다.

#Makefile.am

# 실행 바이너리 파일의 이름은 hello

bin_PROGRAMS = hello

# hello의 소스 코드는 hello.c, hello.h

hello_SOURCES = hello.c hello.h

출력된 Makefile.in은 매우 길어서 게재하지 않지만, 기대한 내용을 얻을 수 있다. 즉, configure를 실행하여 Makefile이 생성된다. 이 Makefile을 사용하여 make 명령어를 사용하면, hello.c를 C 컴파일러로 컴파일하고, 이어서 표준 라이브러리와 링크하여, hello의 실행 파일을 얻을 수 있다. make install에서는 hello가 적절한 위치(대부분의 경우 /usr/local/bin)에 설치된다.

2. 3. GNU Libtool

GNU Libtool은 GNU 유틸리티 중 하나이다.[3]

2. 4. 기타 도구

GNU Autoconf, Automake, Libtool은 오토툴을 구성하는 유틸리티이다.[3] 이 외에도 GNU make, GNU gettext, pkg-config, GNU 컴파일러 모음 (GCC) 등이 관련 도구로 꼽힌다.

3. 사용 방법

GNU 빌드 시스템(Autotools)은 소프트웨어 프로그램을 여러 운영체제 및 환경에 쉽게 이식할 수 있도록 돕는 도구 모음이다. 다양한 시스템 간의 차이점(예: 컴파일러 종류, 라이브러리 함수 유무, 헤더 파일 이름 등)을 자동으로 처리하여 개발자가 복잡한 설정 없이 소스 코드를 배포할 수 있게 해준다.[4][5]

Autotools를 사용하는 일반적인 과정은 다음과 같다.

1. 소스 코드를 다운로드 받는다.

2. 터미널에서 소스 코드 디렉토리로 이동한다.

3. `configure` 스크립트를 실행한다. (`./configure`) 이 스크립트는 현재 시스템 환경을 분석하여 빌드에 필요한 설정 파일(`Makefile` 등)을 생성한다.[11]

4. `make` 명령어를 실행하여 프로그램을 빌드한다.

5. `make install` 명령어를 실행하여 프로그램을 시스템에 설치한다. (선택 사항)

많은 오픈 소스 소프트웨어가 이 방식을 따르고 있으며, `./configure && make && make install` 명령어를 통해 간단하게 설치할 수 있다.

`configure` 스크립트는 빌드 환경 구축을 자동으로 수행하는 셸 스크립트이다.[11] 사용자는 `configure`를 실행하여 빌드 환경을 쉽게 구축할 수 있다. 이 스크립트 및 관련 파일들은 표준적인 UNIX 명령만 사용하므로, 특별한 소프트웨어를 설치할 필요가 없다. 단, Windows에서는 Cygwin이나 MSYS와 같은 UNIX 호환 환경을 설치해야 할 수 있다.

`configure` 스크립트는 다양한 옵션을 제공하여 사용자가 빌드 설정을 세밀하게 조정할 수 있도록 돕는다. (자세한 내용은 "configure 스크립트 옵션" 하위 섹션 참고)

Autotools는 빌드 머신에서 네이티브 프로그램을 빌드하는 것 외에도, 다른 아키텍처로의 크로스 컴파일을 지원한다.[6] 예를 들어, Linux 시스템에서 Windows용 소프트웨어를 크로스 컴파일할 수 있다.

3. 1. configure 스크립트 옵션

autoconf로 생성된 configure 스크립트는 다양한 라이브러리, 헤더 파일 및 언어 기능이 있는지 테스트하기 위해 C 컴파일러와 같은 프로그램을 여러 번 실행하기 때문에 느릴 수 있다. 이러한 자동 환경 검사가 바람직하지 않거나 특별한 설정이 필요한 경우, 사용자는 환경 변수 또는 명령 인수를 통해 configure의 동작을 조정할 수 있다.

대표적인 옵션은 다음과 같다.

옵션설명
--prefix=dir설치 대상을 변경한다. 예를 들어 --prefix=/opt/huga로 설정하면 실행 파일은 /opt/huga/bin, 라이브러리는 /opt/huga/lib와 같이 변경된다. bin, lib 등을 개별적으로 변경할 수도 있다. 기본값은 /usr/local이다. OS 벤더 등이 제공하는 바이너리 패키지에서는 --prefix=/usr나 --prefix=/opt/huga 등의 설정으로 구축되는 경우가 많다. root 권한이 없는 사용자나 시험 삼아 이용하고 싶은 경우에는 --prefix=$HOME/huga 등으로 설정하여 다른 사용자에게 영향을 주는 것을 방지할 수 있다.
--with-hoge다른 패키지 hoge를 이용하는 것을 지정한다. --with-hoge=dir로 hoge의 설치 대상을 지정할 수 있는 경우도 있다. --with-hoge=no 또는 --without-hoge로 설정하면 반대로 사용하지 않는 것을 지정한다.
환경 변수 CC환경 변수 CC를 설정하면, 그 값이 C 컴파일러의 명령 이름으로 사용된다. 설정하지 않는 경우에는 cc 또는 적절한 OS 표준 컴파일러로 설정되지만, 명시적으로 설정함으로써 표준과 다른 컴파일러를 사용할 수 있다.



이 외에도 많은 옵션이 있으며, 적은 패키지에서도 10개 이상, 많은 패키지에서는 수십에서 100개 이상의 설정 항목이 있다. 사용자의 설정에 모순이 있거나 환경의 기능에 부족함이 있으면 진단 정보를 출력한다. 또한, 크로스 컴파일 지원 및 구축용 작업 디렉터리를 소스 코드와 다른 디렉터리로 설정하는 기능이 있다.

4. 장점 및 비판

GNU 빌드 시스템은 소프트웨어 이식성을 높이는 것을 목표로 하지만, 장점과 함께 비판도 받고 있다.

오토툴(Autotools)은 시스템 간의 컴파일러, 라이브러리, 헤더 파일 차이로 인한 이식성 문제를 해결하는 데 도움을 준다. 조건부 컴파일 코드(`ifdef`)를 사용하는 대신, 오토툴은 이러한 차이를 자동으로 감지하고 처리하여 개발자가 이식성 문제에 덜 신경 쓰도록 돕는다.[12]

프리BSD 개발자 폴-헤닝 캄프는 ACM 큐에 기고한 칼럼에서 GNU 빌드 시스템을 비판했다.[8] 그는 구성 스크립트가 지나치게 많은 자동화된 테스트를 수행하여, 근본적으로 이식성이 결여된 소스 코드를 가린다고 지적했다. 또한 ``와 ``와 같은 기본적인 요소의 존재 여부를 확인하는 것은 불필요하며, 시스템 자원을 낭비한다고 비판했다.[8]

반면, ''Autotools, 2판: GNU Autoconf, Automake 및 Libtool 실무자 가이드''의 저자인 존 칼코트는 오토툴이 다른 빌드 도구(cmake, maven 등)보다 투명하며, 사용자가 빌드 프로세스를 세밀하게 제어할 수 있게 해준다고 옹호했다.[10] 그는 다른 도구들이 빌드 프로세스의 세부 사항을 숨겨 단순성을 제공하지만, 이는 사용자가 프로젝트별 목표를 달성하기 어렵게 만든다고 주장했다. 칼코트는 오토툴의 유연성을 강조하며, 사용자가 `configure.ac` 파일에 셸 스크립트를, `Makefile.am` 파일에 make 스크립트를 추가할 수 있다는 점을 예시로 들었다.[10]

4. 1. 장점

GNU 빌드 시스템은 소프트웨어 이식성을 높이는 데 여러 장점을 제공한다. 시스템마다 컴파일러, 라이브러리 함수, C 헤더 파일, 공유 라이브러리 등이 다를 수 있는데, 이러한 차이를 처리하기 위해 조건부 컴파일 코드(예: `#ifdef`)를 사용하면 코드가 복잡해지고 관리하기 어려워진다. 하지만 오토툴(Autotools)을 사용하면 이러한 문제들을 보다 쉽게 관리할 수 있다.[12]

Autotools를 사용하여 만들어진 패키지는 설치가 간편하다. 일반적으로 소스 코드를 전개한 후 다음 명령어를 실행하면 설치까지의 모든 과정이 자동화된다.[12]

```console

$ ./configure && make && make install

```

이 방식은 많은 UNIX용 오픈 소스 소프트웨어에서 채택하고 있다.[12]

Autoconf는 기능 기반으로 이식성 평가를 수행하여 다음과 같은 이점을 제공한다.

  • 패키지 개발 후에 등장한 새로운 시스템에서도 잘 작동한다.
  • 사용자 정의 환경에도 잘 대응할 수 있다.
  • 버전이나 패치 등을 상세하게 파악할 필요가 없다.

4. 2. 비판

GNU 빌드 시스템은 소프트웨어 이식성을 높이기 위해 개발되었지만, 여러 가지 비판을 받고 있다.

폴-헤닝 캄프는 GNU 빌드 시스템이 불필요하게 복잡하고 비효율적이라고 비판했다. 그는 구성 스크립트가 수많은 자동화된 테스트를 수행하여 이식성이 떨어지는 소스 코드를 가리는 경향이 있다고 지적했다.[8] 그는 또한 ``와 ``와 같이 기본적인 요소의 존재 여부를 확인하는 것은 불필요하다고 비판했다.[8]

autoconf로 생성된 configure 스크립트는 C 컴파일러 등을 여러 번 실행하여 라이브러리, 헤더 파일, 언어 기능 등을 테스트하기 때문에 느릴 수 있다. 이는 특히 Cygwin과 같이 네이티브 fork 시스템 호출이 없는 환경에서 두드러진다.[7]

반면, 존 칼코트는 오토툴이 다른 빌드 도구보다 투명하며, 사용자가 빌드 프로세스를 세밀하게 제어할 수 있게 해준다고 옹호했다. 그는 다른 도구들이 빌드 프로세스의 세부 사항을 숨겨 단순성을 제공하지만, 이는 사용자가 프로젝트별 목표를 달성하기 어렵게 만든다고 주장했다.[10] 그는 오토툴의 유연성을 강조하며, 사용자가 `configure.ac` 파일에 셸 스크립트를, `Makefile.am` 파일에 make 스크립트를 추가할 수 있다는 점을 들었다.[10]

5. 대안

GNU 빌드 시스템은 소프트웨어 이식성 문제를 해결하기 위해 설계되었지만, 여러 대안들이 존재한다.

폴-헤닝 캄프는 GNU 빌드 시스템의 복잡성과 비효율성을 비판하며, 구성 스크립트가 수많은 자동화된 테스트를 수행하는 것이 1980년대부터 비판받아온 아이디어라고 지적했다.[8] 그는 소스 코드가 구성 스크립트 뒤에서 이식 가능한 척하는 것이 문제라고 주장했다. 캄프는 <sys/stat.h>영어와 <stdlib.h>영어의 존재 여부를 확인하는 libtool의 방대한 구성 스크립트를 예시로 들었다.[8]

반면, 존 칼코트는 오토툴이 다른 빌드 도구보다 투명하다고 주장하며, cmake, maven, gradle 등의 도구들이 빌드 프로세스의 세부 사항을 사용자로부터 격리시켜 단순성을 제공하지만, 이는 사용자가 프로젝트별 빌드 목표를 달성하기 위한 변경을 어렵게 만든다고 지적했다.[10] 그는 오토툴의 경우 configure.ac 파일에 셸 스크립트를, Makefile.am 파일에 make 스크립트를 넣을 수 있는 유연성을 제공하는 것이 투명성의 정의라고 강조했다.[10]

참조

[1] 웹사이트 Savannah Git Hosting - autoconf.git/blob - COPYING.EXCEPTION https://web.archive.[...] 2016-04-01
[2] 웹사이트 libtool.git - GNU Libtool http://git.savannah.[...] 2016-04-01
[3] 웹사이트 Learning the GNU development tools http://autotoolset.s[...] 2016-04-01
[4] 웹사이트 automake: GNU Build System https://www.gnu.org/[...] 2016-04-01
[5] 웹사이트 The GNU configure and build system - Introduction http://airs.com/ian/[...] 2016-04-01
[6] 웹사이트 Cross Compilation with GNU Autotools https://web.archive.[...] 2008-09-24
[7] 웹사이트 Robert Ögren - Slow shell script execution on Cygwin http://cygwin.com/ml[...] 2016-04-01
[8] 간행물 A Generation Lost in the Bazaar
[9] 웹사이트 Autotools, 2nd Edition by John Calcote {{!}} Penguin Random House Canada https://www.penguinr[...] 2021-01-22
[10] 웹사이트 Re: Future plans for Autotools https://lists.gnu.or[...] 2021-01-22
[11] 문서 The configuration scripts that Autoconf produces are by convention called configure. When run, configure creates several files, replacing configuration parameters in them with appropriate values. https://www.gnu.org/[...] 3 Making configure Scripts - Autoconf - gnu.org 2022-06-11
[12] 문서 Autoconf is an extensible package of M4 macros that produce shell scripts to automatically configure software source code packages. https://www.gnu.org/[...] Autoconf - gnu.org.
[13] 문서 To create a configure script with Autoconf, you need to write an Autoconf input file configure.ac https://www.gnu.org/[...] 3 Making configure Scripts - Autoconf - gnu.org
[14] 문서 GNU Automake is a tool for automatically generating Makefile.in files https://www.gnu.org/[...] Automake - gnu.org 2022-06-11
[15] 문서 Autoconf license exception http://git.savannah.[...]
[16] 문서 libtool HACKING including all pertinent license exceptions http://git.savannah.[...]


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

문의하기 : help@durumis.com