web-dev-qa-db-ja.com

なぜ常に./configure;作る;インストールする; 3つの別々のステップとして？

ソースから何かをコンパイルするたびに、同じ3つの手順を実行します。

$ ./configure
$ make
$ make install

インストールプロセスを異なるステップに分割することは理にかなっていますが、この惑星の各コーダーが同じ3つのコマンドを何度も何度も繰り返して1つのジョブを実行する必要があるのは理解できません。私の観点からすると、次のテキストを含むソースコードで自動的に配信される./install.shスクリプトを持つことは完全に理にかなっています：

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

なぜ人々は3つのステップを別々に行うのですか？

unixmakefileconfiguremake-install
110
erikbwork

各ステップは異なることを行うため

構築のための環境の準備（セットアップ）

./configure

このスクリプトには、変更する必要がある多くのオプションがあります。 --prefixや--with-dir=/fooなど。つまり、すべてのシステムの構成は異なります。また、./configureは、インストールする必要のある欠落ライブラリーをチェックします。ここで何か間違っていると、アプリケーションをビルドできません。すべてのディストリビューションが特定のライブラリとファイルを特定のディレクトリにインストールする方が良いと考えているため、ディストリビューションに異なる場所にインストールされるパッケージがある理由です。 ./configureを実行すると言われていますが、実際には常に変更する必要があります。

たとえば、 Arch Linuxパッケージサイト をご覧ください。ここでは、パッケージが異なる構成パラメーターを使用していることがわかります（ビルドシステムにautotoolsを使用していると仮定します）。

システムの構築

make

これは実際にはデフォルトでmake allです。そして、メーカーごとに異なるアクションがあります。一部はビルドを行い、一部はビルド後にテストを行い、一部は外部SCMリポジトリからチェックアウトを行います。通常、パラメーターを指定する必要はありませんが、いくつかのパッケージはそれらを異なる方法で実行します。

システムにインストールする

make install

これにより、configureで指定された場所にパッケージがインストールされます。必要に応じて、./configureを指定して、ホームディレクトリを指すことができます。ただし、多くの構成オプションは/usrまたは/usr/localを指しています。つまり、rootのみが/ usrおよび/ usr/localにファイルをコピーできるため、実際にSudo make installを使用する必要があります。

これで、各ステップが次のステップの前提条件であることがわかります。各ステップは、問題のないフローで物事を機能させるための準備です。ディストリビューションはこの比metaを使用してパッケージ（RPM、debなど）を構築します。

ここでは、各ステップが実際には異なる状態であることがわかります。これが、パッケージマネージャーのラッパーが異なる理由です。以下は、パッケージ全体を1ステップでビルドできるラッパーの例です。ただし、各アプリケーションには異なるラッパーがあることに注意してください（実際、これらのラッパーには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

ここではオートツールを使用できます。つまり、./configure、make、およびmake installを使用できます。しかし、別のものは、SCons、Python関連のセットアップ、または異なるものを使用できます。

ご覧のとおり、各状態を分割すると、特にパッケージメンテナーやディストリビューションの場合、メンテナンスと展開が非常に簡単になります。

115
Fatih Arslan

まず、それぞれが前者の成功に依存するため、./configure && make && make installである必要があります。理由の一部は進化であり、理由の一部は開発ワークフローの利便性です。

元々、ほとんどのMakefilesにはプログラムをコンパイルするためのコマンドのみが含まれ、インストールはユーザーに任されていました。追加の規則により、make installはコンパイルされた出力を正しい場所に配置できます。システム管理者ではない、まったくインストールしたくないなど、これを行いたくない理由がまだたくさんあります。さらに、ソフトウェアを開発している場合、おそらくインストールしたくないでしょう。いくつかの変更を行い、ディレクトリにあるバージョンをテストしたいと思います。複数のバージョンが存在する場合、これはさらに顕著になります。

./configureは、環境で利用可能なもの、および/またはソフトウェアの構築方法を決定するためにユーザーが望むものを検出します。これは非常に頻繁に変更する必要があるものではなく、多くの場合時間がかかることがあります。繰り返しになりますが、私が開発者である場合、絶えず再構成するのは価値がありません。さらに重要なことは、makeはタイムスタンプを使用してモジュールを再構築するため、configureを再実行すると、フラグが変更される可能性があり、ビルド内の一部のコンポーネントが1つのフラグセットでコンパイルされ、別のフラグセットでコンパイルされる可能性があります異なる、互換性のない動作につながります。 configureを再実行しない限り、ソースを変更してもコンパイル環境は同じままです。 configureを再実行する場合、最初にmake cleanを実行して、ビルドされたソースを削除して、物事が均一にビルドされるようにします。

3つのコマンドが連続して実行される唯一のケースは、ユーザーがプログラムをインストールしたとき、またはパッケージがビルドされたときです（例：DebianのdebuildまたはRedHatのrpmbuild）。そしてそれは、パッケージにプレーンなconfigureを与えることができることを前提としています。これは通常、少なくとも--prefix=/usrが望まれるパッケージングには当てはまりません。そして、パッカッカーは、make installの部分を実行するときに、偽のルートを処理する必要があります。多くの例外があるため、./configure && make && make installをルールにすることは、はるかに頻繁にそれを行う多くの人々にとって不便です！

29
apmasell

configureは、依存関係が欠落していることが検出されると失敗する場合があります。

makeは、Makefileにリストされている最初のターゲットであるデフォルトターゲットを実行します。多くの場合、このターゲットはallですが、常にではありません。そのため、それがターゲットであることを知っていた場合のみ、make all installしかできませんでした。

そう ...

#!/bin/sh

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

または：

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

多くの場合、configureにオプションを提供する必要があるため、$*が含まれています。

しかし、なぜ人々が自分でそれをできるようにしないのですか？これは本当に大きな勝利ですか？

3
ghoti

まず、。/ configureは常に必要なものをすべて見つけられるわけではありません。また、他の場合には、必要なすべてを見つけますが、使用できるすべてを見つけるわけではありません。その場合、あなたはそれについて知りたいと思うでしょう（そしてあなたの./install.shスクリプトはとにかく失敗します！）私の観点から、意図しない結果を伴う非失敗の典型的な例は、ffmpegやmplayerのような大きなアプリケーションをコンパイルしています。これらは利用可能な場合はライブラリを使用しますが、利用できない場合はコンパイルし、一部のオプションを無効のままにします。問題は、何らかの形式をサポートせずにコンパイルされたことを後で発見するため、元に戻ってやり直す必要があることです。

./configureがやや対話的に行うもう1つのことは、アプリケーションをシステム上のどこにインストールするかをカスタマイズするオプションを提供することです。異なるディストリビューション/環境には異なる規則があり、おそらくシステムの規則に固執したいと思うでしょう。また、ローカルに（自分でのみ）インストールすることもできます。従来、。/ configureおよびmakeステップはrootとして実行されませんが、make install（自分用にインストールされている場合を除く）はrootとして実行する必要があります。

特定のディストリビューションは、多くの場合、この./install.sh機能をディストリビューションに依存した方法で実行するスクリプトを提供します。たとえば、 ソースRPM +スペックファイル+ rpmbuild または slackbuilds です。

（脚注：言われているとおり、。/ configure; make; make install;は非常に退屈になります。）

3
Soz