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

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

$ ./configure
$ make
$ make install

インストールプロセスを複数のステップに分割することは理にかなっていますが、理解できません。この惑星のすべてのコーダーが同じ3つのコマンドを何度も何度も記述して、1つのジョブを完了する必要があるのです。私の観点から./install.shは、次のテキストを含むソースコードと共にスクリプトが自動的に配信されるようにするのはまったく理にかなっています。

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

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

各ステップは異なることをするので

ビルドのための環境を準備（セットアップ）します

./configure

このスクリプトには、変更する必要がある多くのオプションがあります。同様--prefixか--with-dir=/foo。つまり、システムごとに構成が異なります。また./configure、インストールする必要のあるライブラリがないかどうかを確認します。ここで問題が発生すると、アプリケーションがビルドされません。すべてのディストリビューションが特定のライブラリとファイルを特定のディレクトリにインストールする方が良いと考えているため、ディストリビューションにはさまざまな場所にインストールされるパッケージがあります。実行すると言われています./configureが、実際には常に変更する必要があります。

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

システムの構築

make

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

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

make install

これにより、configureで指定された場所にパッケージがインストールされます。必要に応じ./configureて、ホームディレクトリを指すように指定できます。ただし、多くの設定オプションが/usrまたはを指しています/usr/local。つまり、sudo make installrootだけが/ 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のにはプログラムをコンパイルするコマンドのみが含まれ、インストールはユーザーに任されていました。追加のルールにより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は常に必要なものすべてを見つけるわけではありません。また、必要なすべてを見つけて、使用できるすべてのものを見つけるわけではありません。その場合、それについて知りたいと思います（そして、。/ install.shスクリプトはとにかく失敗します！）私の観点から、意図しない結果を伴う失敗以外の典型的な例は、ffmpegやmplayerなどの大きなアプリケーションをコンパイルすることです。これらは、使用可能な場合はライブラリを使用しますが、使用できない場合はとにかくコンパイルして、一部のオプションを無効のままにします。問題は、後で何らかの形式のサポートなしでコンパイルされたため、戻ってやり直す必要があることを後で発見することです。

./configureがやや対話的に行うもう1つのことは、アプリケーションがインストールされるシステム上の場所をカスタマイズするオプションを提供することです。ディストリビューション/環境が異なれば、規約も異なります。おそらく、システムの規約に準拠したいと思うでしょう。また、それをローカルにインストールすることもできます（自分だけで）。伝統的に./configureとmakeのステップはrootとして実行されませんが、make install（自分だけでインストールされない限り）はrootとして実行される必要があります。

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

（脚注：言われていることですが、。/ configure; make; make install;非常に退屈になる可能性があることに同意します。）

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

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

そう ...

#!/bin/sh

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

または：

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

$*1は、多くの場合にオプションを提供しなければならないため、含まれていますconfigure。

しかし、なぜ人々に自分でやらせないのか？これは本当に大きな勝利なのでしょうか？