왜 항상 ./configure; 하다; 설치하십시오. 3 단계로?

소스에서 무언가를 컴파일 할 때마다 동일한 3 단계를 거칩니다.

$ ./configure
$ make
$ make install

설치 과정을 여러 단계로 나누는 것이 합리적이라는 것을 이해합니다.하지만 이해가 안되며,이 행성의 모든 코더가 하나의 작업을 완료하기 위해 동일한 세 가지 명령을 반복해서 작성해야하는 이유를 이해합니다. 내 관점에서 볼 때 ./install.sh다음 텍스트를 포함하는 소스 코드와 함께 스크립트가 자동으로 전달되는 것이 전적으로 합리적입니다 .

#!/bin/sh
./configure
make
make install

왜 사람들은 3 단계를 따로하나요?

각 단계마다 다른 일을하기 때문에

건물 환경 준비 (설정)

./configure

이 스크립트에는 변경해야하는 많은 옵션이 있습니다. 좋아요 --prefix또는 --with-dir=/foo. 이는 모든 시스템이 다른 구성을 가지고 있음을 의미합니다. 또한 ./configure설치해야하는 누락 된 라이브러리를 확인합니다. 여기에 잘못된 것이 있으면 응용 프로그램을 빌드하지 않습니다 . 그렇기 때문에 모든 배포판은 특정 라이브러리와 파일을 특정 디렉토리에 설치하는 것이 더 낫다고 생각하기 때문에 배포판에는 다른 위치에 설치된 패키지가 있습니다. run이라고 ./configure하지만 실제로는 항상 변경해야합니다.

예를 들어 Arch Linux 패키지 사이트를 살펴보십시오 . 여기에서 모든 패키지가 다른 구성 매개 변수를 사용하는 것을 볼 수 있습니다 (빌드 시스템에 autotools를 사용한다고 가정).

시스템 구축

make

이것은 실제로 make all기본입니다. 그리고 모든 메이크는 할 일이 다릅니다. 일부는 빌드하고, 일부는 빌드 후 테스트를, 일부는 외부 SCM 저장소에서 체크 아웃합니다. 일반적으로 매개 변수를 제공 할 필요가 없지만 일부 패키지는 매개 변수를 다르게 실행합니다.

시스템에 설치

make install

이렇게하면 configure로 지정된 위치에 패키지가 설치됩니다. 원하는 경우 ./configure홈 디렉토리를 가리 키도록 지정할 수 있습니다 . 그러나 많은 구성 옵션이 /usr또는을 가리키고 있습니다 /usr/local. 즉, sudo make install루트 만 / usr 및 / usr / local에 파일을 복사 할 수 있기 때문에 실제로 사용해야 합니다.

이제 각 단계가 다음 단계의 사전 요구 사항임을 알 수 있습니다. 각 단계는 문제없는 흐름에서 작업을 수행하기위한 준비입니다. 배포판은이 은유를 사용하여 패키지 (RPM, deb 등)를 빌드합니다.

여기에서 각 단계가 실제로 다른 상태임을 알 수 있습니다. 이것이 패키지 관리자가 다른 래퍼를 갖는 이유입니다. 다음은 한 단계로 전체 패키지를 빌드 할 수있는 래퍼의 예입니다. 그러나 각 응용 프로그램에는 서로 다른 래퍼가 있습니다 (실제로 이러한 래퍼에는 spec, PKGBUILD 등과 같은 이름이 있음) :

def setup:
... #use ./configure if autotools is used

def build:
... #use make if autotools is used

def install:
... #use make all if autotools is used

여기서 autotools, 즉 ./configure, make및 make install. 그러나 다른 하나는 SCons, Python 관련 설정 또는 다른 것을 사용할 수 있습니다.

보시다시피 각 상태를 분할하면 특히 패키지 관리자 및 배포자에게 유지 관리 및 배포가 훨씬 쉬워집니다.

첫째, ./configure && make && make install각각은 전자의 성공에 달려 있기 때문입니다. 그 이유 중 일부는 진화이고 그 이유 중 일부는 개발 워크 플로의 편의성입니다.

원래 대부분 Makefile의 s에는 프로그램을 컴파일하는 명령 만 포함되어 있으며 설치는 사용자에게 맡겨졌습니다. 추가 규칙을 사용 make install하면 컴파일 된 출력을 올바른 위치에 배치 할 수 있습니다. 시스템 관리자가 아니거나 전혀 설치하지 않는 것을 포함하여이 작업을 원하지 않을 수있는 충분한 이유가 있습니다. 또한 소프트웨어를 개발 중이라면 설치하고 싶지 않을 것입니다. 몇 가지 변경을하고 내 디렉토리에있는 버전을 테스트하고 싶습니다. 여러 버전이있을 경우 더욱 두드러집니다.

./configure소프트웨어를 구축하는 방법을 결정하기 위해 사용자가 원하는 환경 및 / 또는 원하는 것을 감지합니다. 이것은 매우 자주 변경해야하는 것이 아니며 종종 시간이 걸릴 수 있습니다. 다시 말하지만, 내가 개발자라면 지속적으로 재구성 할 시간이 없습니다. 더 중요한 것은 make타임 스탬프를 사용하여 모듈을 다시 빌드하기 때문에 다시 실행 configure하면 플래그가 변경 될 가능성이 있으며 이제 빌드의 일부 구성 요소가 한 플래그 집합으로 컴파일되고 다른 플래그 집합으로 이어질 수있는 다른 플래그 집합으로 컴파일됩니다. 서로 다른, 호환되지 않는 행동. 다시 실행하지 않는 한 configure소스를 변경하더라도 컴파일 환경이 동일하게 유지된다는 것을 알고 있습니다. 다시 실행 configure하면make clean 첫째, 빌드 된 소스를 제거하여 일관되게 빌드되도록합니다.

세 개의 명령이 연속적으로 실행되는 유일한 경우는 사용자가 프로그램을 설치하거나 패키지를 빌드 할 때입니다 (예 : Debian의 debuild 또는 RedHat의 rpmbuild). 그리고 그것은 패키지 configure가 보통 포장의 경우가 아닌 평범한 것으로 주어질 수 있다고 가정합니다 --prefix=/usr. 그리고 pacakgers는 그 make install역할을 할 때 가짜 뿌리를 다루어야하는 것과 같습니다 . 예외가 많기 때문에 ./configure && make && make install규칙을 만드는 것은 훨씬 더 자주하는 많은 사람들에게 불편할 것입니다!

첫째, ./configure는 항상 필요한 모든 것을 찾지 못하거나 다른 경우에는 필요한 모든 것을 찾지 만 사용할 수있는 모든 것을 찾지는 않습니다. 이 경우 당신은 그것에 대해 알고 싶을 것입니다 (그리고 당신의 ./install.sh 스크립트는 어쨌든 실패 할 것입니다!) 제 관점에서 의도하지 않은 결과로 실패하지 않는 고전적인 예는 ffmpeg 또는 mplayer와 같은 대형 응용 프로그램을 컴파일하는 것입니다. 사용 가능한 경우 라이브러리를 사용하지만 그렇지 않은 경우 어쨌든 컴파일하여 일부 옵션을 비활성화합니다. 문제는 나중에 어떤 형식이나 다른 형식을 지원하지 않고 컴파일되었으므로 다시 돌아가서 다시 실행해야한다는 것입니다.

./configure가 다소 대화식으로 수행하는 또 다른 기능은 시스템에서 응용 프로그램을 설치할 위치를 사용자 지정할 수있는 옵션을 제공하는 것입니다. 배포판 / 환경마다 규칙이 다르므로 시스템 규칙을 고수하고 싶을 것입니다. 또한 로컬로 설치할 수도 있습니다 (사용자 전용). 전통적으로 ./configure 및 make 단계는 루트로 실행되지 않지만 make install (자신만을 위해 설치되지 않는 한)은 루트로 실행되어야합니다.

특정 배포판은 종종 배포에 민감한 방식으로이 ./install.sh 기능을 수행하는 스크립트를 제공합니다 (예 : 소스 RPMs + 사양 파일 + rpmbuild 또는 slackbuilds) .

(각주 : 즉, ./configure; make; make install; 매우 지루할 수 있음에 동의합니다.)

configure 종속성이 누락 된 경우 실패 할 수 있습니다.

makeMakefile에 나열된 첫 번째 대상인 기본 대상을 실행합니다. 종종이 목표는 all이지만 항상 그런 것은 아닙니다. 그래서 당신은 make all install그것이 목표라는 것을 알고 있을 때만 가능했습니다.

그래서 ...

#!/bin/sh

if ./configure $*; then
  if make; then
    make install
  fi
fi

또는:

./configure $* && ./make && ./make install

는 $*사람이 종종 옵션을 제공하기 때문에 포함되어 있습니다 configure.

하지만 왜 사람들이 스스로하도록 두지 않는가? 이게 정말 큰 승리인가요?