makefileに「インストール」ターゲットが必要なのはなぜですか？

CとC ++の世界から来たほとんどのビルドシステムには、installターゲット、特にMakefiles（たとえばGNUが推奨する場所）またはCMakeがあります。このターゲットは、オペレーティングシステム（C:\Program Files\Windowsなど）のランタイムファイル（実行可能ファイル、ライブラリなど）をコピーします。

私にとっては、プログラムをインストールすることはビルドシステムの責任ではないため（実際にはオペレーティングシステム/パッケージマネージャーの責任です）、これは非常にハッキリしています。また、ビルドシステムまたはビルドスクリプトは、環境変数、レジストリ変数、シンボリックリンク、権限などを使用して、インストールされたプログラムの構成を認識している必要があります。

せいぜい、ビルドシステムにはrelease、インストール可能なプログラム（.debまたはなど.msi）を出力するターゲットがあり、そのプログラムをインストールするようオペレーティングシステムに親切に依頼する必要があります。また、ユーザーはを入力せずにアンインストールできmake uninstallます。

だから、私の質問：ビルドシステムは通常、installターゲットを持つことを推奨するのはなぜですか？

多くのビルドスクリプトまたはMakefileには、パッケージマネージャーが存在する前に作成されたため、および今日でも多くのシステムにパッケージマネージャーがないため、インストールターゲットがあります。プラス、方式がありmake install、実際にあるパッケージを管理するための好ましい方法は。

Aにmakefileはinstallターゲットがない場合があり、さらに重要なことには、インストール可能でないはずのプログラムを使用できます（たとえば、ビルドディレクトリから実行する必要があるため、またはどこにでもインストールできるため）。install目標はただで大会通常のためのmakefile-s。

ただし、多くのプログラムでは外部リソースの実行が必要です（たとえば、フォント、データベース、構成ファイルなど）。そして、それらの実行可能ファイルは、これらのリソースについてしばしば仮説を立てます。たとえば、bashシェルは通常、/etc/bash.bashrcなどから初期化ファイルを読み取ります。これらのリソースは一般にファイルシステムにあり（ファイル階層に関する規則についてはhier（7）を参照）、デフォルトのファイルパスは実行可能ファイルに組み込まれます。

システムのほとんどの実行可能ファイルで、strings（1）を使用してみてください。どのファイルパスが認識されているかがわかります。

ところで、を使用する多くのGNUプログラムではautoconf、make install DESTDIR=/tmp/destdir/rootにならずに実行できます。その後/tmp/destdir/、後でパッケージ化する必要のあるファイルで満たされます。

FWIW、私はbismon（GPLv3 +ライセンス）プログラム（bismon-chariot-doc.pdfレポートに記載）を「インストール」できないと信じがちです。それを証明できるかどうかはわかりませんが、そのプログラムをインストール可能にする方法を想像することはできません。

いくつかの理由が思い浮かびます。

• 多くのパッケージ作成ソフトウェア- たとえばDebianビルドシステム、およびIIRC rpm-は、ビルドスクリプトがプログラムを特別なサブディレクトリに「インストール」することを既に期待しています。そのため、両方向の後方互換性によって駆動されます。
• ユーザーは、$HOMEディレクトリ内などのローカルスペースにソフトウェアをインストールする場合があります。すべてのパッケージマネージャーがサポートしているわけではありません。
• パッケージがない環境がまだある場合があります。

言及されていない理由の1つは、現在のバージョンのソフトウェアを使用していない場合や、ソフトウェアの修正バージョンを使用していない場合が多いことです。カスタムパッケージを作成しようとすると、作業が増えるだけでなく、現在作成および配布されているパッケージと競合する可能性があります。オープンソースコードでは、特に使用している将来のバージョンで重大な変更が導入された場合、これが頻繁に発生します。

現在バージョン2.0.1にあるオープンソースプロジェクトFOOを使用しており、バージョン1.3.0を使用しているとします。バージョン2.0.0は現在実行しているものと互換性がないため、上記のものは使いたくありませんが、2.0.1には1つのバグ修正が必要です。このmake installオプションを使用すると、パッケージを作成してシステムにインストールすることを心配せずに、変更された1.3.0ソフトウェアをインストールできます。

Linuxディストリビューションでは、通常、プログラムのメンテナンスとパッケージのメンテナンスが分離されています。パッケージ生成を統合するビルドシステムは、プログラムメンテナーにパッケージメンテナンスの実行も強制します。

これは通常悪い考えです。ディストリビューションには、内部の整合性を検証し、複数のターゲットプラットフォームにバイナリを提供し、システムの他の部分とよりよく統合するための小さな変更を実行し、バグを報告するユーザーに一貫したエクスペリエンスを提供するためのインフラストラクチャがたくさんあります。

ビルドシステムからパッケージを直接生成するには、このインフラストラクチャをすべて統合するかバイパスする必要があります。それを統合することは疑わしい利益のために多くの作業であり、それをバイパスするとユーザーエクスペリエンスが低下します。

これは、マルチパーティシステムで一般的な「食物連鎖のトップ」の問題の1つです。複数の複雑なシステムがある場合は、他のすべてのシステムを調整する責任があるシステムの明確な階層が必要です。

ソフトウェアインストール管理の場合、パッケージマネージャーはこのコンポーネントであり、パッケージのビルドシステムを実行し、便利なインターフェイス（「インストール手順後のディレクトリ内のファイル」）を介して出力を取得し、パッケージを生成して準備しますリポジトリへのアップロード用。

パッケージマネージャーは、ビルドシステムとリポジトリの中間に位置し、両方とうまく統合できる最適な位置にあります。

あなたはを通して利用可能なパッケージのJavaScriptのほんの数があることに気づいたかもしれませんnpmからも利用できるapt-これはJavaScriptの人々がいることを決めたので、主ですnpmと関連リポジトリがすることは不可能に近いそれを作った彼らの食物連鎖の最上位になる予定でしたこれらのパッケージをDebianパッケージとして出荷します。

Debian開発者の帽子をかぶって：もしあなたがオープンソースソフトウェアをリリースしたら、パッケージをディストリビューションのメンテナーに任せてください。それはあなたと私たちの両方の多くの仕事を節約します。

さて、アプリケーション開発者は、各ファイルがどこに行くべきかを知っています。それらをドキュメントに残し、パッケージメンテナにそれを読み取らせ、各パッケージのスクリプトを作成することができます。パッケージメンテナーがドキュメントを誤って解釈し、スクリプトが機能するまでデバッグする必要があるかもしれません。これは非効率的です。アプリケーション開発者は、作成したアプリケーションを適切にインストールするためのスクリプトを作成する方が適切です。

彼は、インストールスクリプトを任意の名前で作成するか、他のスクリプトの手順の一部にすることができます。ただし、標準のインストールコマンドmake install（パッケージマネージャーより前の慣例）があるため、パッケージの作成は非常に簡単になりました。Archlinuxパッケージを作成するためのPKGBUILDテンプレートを見ると、実際にパッケージ化する機能が単に.aを実行することがわかりますmake DESTDIR="$pkgdir/" install。これはおそらく大部分のパッケージで機能し、おそらく少し変更するだけでさらに機能します。おかげでmake、標準的なもの（とautotoolsのは）、パッケージングは本当に、本当に簡単です。