ソースから何かをコンパイルするたびに、同じ 3 つの手順を実行します。
$ ./configure
$ make
$ make install
インストールプロセスを異なるステップに分割するのは理にかなっていることは理解していますが、この地球上のすべてのコーダーが、1 つのジョブを完了するためだけに同じ 3 つのコマンドを何度も記述しなければならない理由がわかりません。私の観点からすると./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 にコピーできるため、実際に使用する必要があります。
これで、各ステップが次のステップの前提条件であることがわかります。各ステップは、問題のない流れで物事を機能させるための準備です。ディストリビューションは、このメタファを使用してパッケージ (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
ここでは autotools を使用できます。つまり./configure、makeとmake installです。しかし、もう 1 つは SCons、Python 関連のセットアップ、または別のものを使用できます。
ご覧のとおり、各状態を分割すると、特にパッケージのメンテナーとディストリビューションにとって、保守と展開がはるかに簡単になります。
./configure && make && make installまず、それぞれが前者の成功に依存するため、そうあるべきです。その理由の一部は進化であり、理由の一部は開発ワークフローの利便性です。
当初、ほとんどMakefileの s にはプログラムをコンパイルするためのコマンドのみが含まれており、インストールはユーザーに任されていました。追加のルールによりmake install、コンパイルされた出力を正しい場所に配置できます。システム管理者ではない、まったくインストールしたくないなど、これをしたくない理由はまだたくさんあります。さらに、ソフトウェアを開発している場合は、おそらくインストールしたくありません。いくつかの変更を加えて、ディレクトリにあるバージョンをテストしたいと考えています。複数のバージョンが横たわっている場合、これはさらに顕著になります。
./configureソフトウェアの構築方法を決定するために、環境で利用可能なもの、および/またはユーザーが必要としているものを検出します。これは、頻繁に変更する必要があるものではなく、多くの場合、時間がかかるものです。繰り返しますが、私が開発者である場合、常に再構成するのに時間をかける価値はありません。さらに重要なことは、makeタイムスタンプを使用してモジュールを再構築するため、再実行configureするとフラグが変更される可能性があり、ビルド内のコンポーネントの一部が 1 つのフラグ セットでコンパイルされ、他のコンポーネントが別のフラグ セットでコンパイルされる可能性があることです。異なる、互換性のない動作。を再実行しない限りconfigure、ソースを変更してもコンパイル環境は変わらないことがわかっています。再実行する場合はconfigure、make cleanまず、ビルドされたソースを削除して、物事が均一にビルドされるようにします。
3 つのコマンドが連続して実行される唯一のケースは、ユーザーがプログラムをインストールするとき、またはパッケージがビルドされるときです (たとえば、Debian の debuild または RedHat の rpmbuild)。そして、それはパッケージにプレーンを与えることができることを前提としていますconfigure。これは通常、パッケージングの場合ではありませんが、少なくとも--prefix=/usr必要な場合です。そして、パッカーは、その役割を果たしているときに偽の根に対処しなければならないようなものmake installです. 例外がたくさんあるので./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。
しかし、人々に自分でやらせてみませんか？これは本当に大きな勝利ですか？
まず、./configure は常に必要なものをすべて見つけるとは限りません。または、必要なものはすべて見つけることができますが、使用できるものすべてを見つけるわけではありません。その場合、それについて知りたいと思うでしょう (そして、あなたの ./install.sh スクリプトはとにかく失敗します!) 私の観点からすると、意図しない結果を伴う失敗しない典型的な例は、ffmpeg や mplayer のような大規模なアプリケーションをコンパイルすることです。これらは、利用可能な場合はライブラリを使用しますが、利用できない場合はとにかくコンパイルし、一部のオプションを無効のままにします。問題は、後でそれが何らかのフォーマットのサポートなしでコンパイルされたことに気づき、戻ってやり直す必要があることです。
./configure がインタラクティブに行うもう 1 つのことは、アプリケーションがインストールされるシステム上の場所をカスタマイズするオプションを提供することです。異なるディストリビューション/環境には異なる規則があり、おそらくシステムの規則に固執したいと思うでしょう。また、ローカルにインストールすることもできます (自分用にのみ)。従来、./configure と make の手順は root として実行されませんが、make install (自分用にインストールする場合を除く) は root として実行する必要があります。
特定のディストリビューションでは、多くの場合、この ./install.sh 機能をディストリビューションに応じた方法で実行するスクリプトが提供されます (たとえば、ソース RPM + 仕様ファイル + rpmbuildまたはslackbuilds )。
(脚注: そうは言っても、./configure; make; make install; が非常に面倒になる可能性があることに同意します。)