왜 항상 ./configure;

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

---

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

$ ./configure
$ make
$ make install

설치 프로세스를 다른 단계로 나누는 것이 합리적이라는 것을 이해하지만,이 행성의 각 코더가 하나의 단일 작업을 수행하기 위해 동일한 세 개의 명령을 반복해서 작성 해야하는 이유를 이해하지 못했습니다. 내 관점에서 볼 때 ./install.sh다음 텍스트를 포함하는 소스 코드와 함께 스크립트를 자동으로 제공 하는 것이 전적으로 의미가 있습니다 .

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

사람들이 왜 3 단계를 따로했을까요?

---

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

건축 환경 준비 (설치)

./configure

이 스크립트에는 변경해야 할 옵션이 많이 있습니다. --prefix또는 처럼 --with-dir=/foo. 즉, 모든 시스템의 구성이 다릅니다. ./configure설치해야하는 누락 된 라이브러리 도 검사합니다. 여기에 문제가 있으면 응용 프로그램을 빌드하지 않습니다 . 모든 배포판에서 특정 라이브러리와 파일을 특정 디렉토리에 설치하는 것이 더 낫다고 생각하기 때문에 배포판에 다른 위치에 패키지가 설치되어있는 이유가 여기에 있습니다. 실행되는 것으로 알려져 ./configure있지만 실제로는 항상 변경해야합니다.

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

시스템 구축

make

이것은 실제로 make all기본적으로입니다. 그리고 모든 제조사는 다른 행동을 취합니다. 일부는 건물을 짓고 일부는 건물을 짓고 테스트를하고 일부는 외부 SCM 리포지토리에서 체크 아웃합니다. 일반적으로 매개 변수를 지정할 필요는 없지만 일부 패키지는 다르게 실행합니다.

시스템에 설치

make install

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

---

이제 각 단계가 다음 단계의 전제 조건임을 알 수 있습니다. 각 단계는 문제없는 흐름으로 작업을 수행하기위한 준비입니다. Distros는이 비유를 사용하여 패키지 (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의 프로그램에는 프로그램을 컴파일하는 명령 만 포함되어 있으며 설치는 사용자에게 맡겨졌습니다. 추가 규칙을 사용 make install하면 컴파일 된 출력을 올바른 위치에 배치 할 수 있습니다. 시스템 관리자가 아니거나 설치를 원하지 않는 등이 작업을 원하지 않는 충분한 이유가 여전히 있습니다. 또한 소프트웨어를 개발 중이라면 설치하고 싶지 않을 것입니다. 디렉토리를 변경하고 버전을 테스트하고 싶습니다. 여러 버전을 둘러 보면 더욱 두드러집니다.

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

The only case where the three command are run in a row are when users install the program or a package is built (e.g., Debian's debuild or RedHat's rpmbuild). And that assumes that the package can be given a plain configure, which is not usually the case for packaging, where, at least, --prefix=/usr is desired. And pacakgers are like to have to deal with fake-roots when doing the make install part. Since there are lots of exceptions, making ./configure && make && make install the rule would be inconvenient for a lot of people who do it on a far more frequent basis!

---

configure may fail if it finds that dependencies are missing.

make runs a default target, the first one listed in the Makefile. Often this target is all, but not always. So you could only make all install if you knew that was the target.

So ...

#!/bin/sh

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

or:

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

The $* is included because one often has to provide options to configure.

But why not just let people do it themselves? Is this really such a big win?

---

Firstly ./configure doesn't always find everything that it needs, or in other cases it finds everything it requires but not everything it could use. In that case you would want to know about it (and your ./install.sh script would fail anyway!) The classic example of non-failure with unintended consequences, from my point of view, is compiling large applications like ffmpeg or mplayer. These will use libraries if they are available but will compile anyway if they aren't, leaving some options disabled. The problem is that you then discover later that it was compiled without support for some format or another, thus requiring you to go back and redo it.

Another thing ./configure does somewhat interactively is giving you the option to customise where on the system the application will be installed. Different distributions/environments have different conventions, and you would probably want to stick to the convention on your system. Also, you might want to install it locally (solely for yourself). Traditionally the ./configure and make steps aren't run as root, while make install (unless it is installed solely for yourself) has to be run as root.

Specific distributions often provide scripts that perform this ./install.sh functionality in a distribution-sensitive manner - for example, source RPMs + spec file + rpmbuild or slackbuilds.

(Footnote: that being said, I agree that ./configure; make; make install; can get extremely tedious.)

참고URL : https://stackoverflow.com/questions/10961439/why-always-configure-make-make-install-as-3-separate-steps