makefileに「インストール」ターゲットが必要なのはなぜですか？
CおよびC++の世界から来て、ほとんどのビルドシステムにはinstallターゲットがあり、特にMakefile（これは GNUで推奨 など）または CMake です。 。このターゲットは、オペレーティングシステム（WindowsのC:\Program Files\など）にランタイムファイル（実行可能ファイル、ライブラリなど）をコピーします。
私にとってプログラムをインストールするのはビルドシステムの責任ではない（これは実際にはオペレーティングシステム/パッケージの責任です）ので、これは本当にハックに感じられますマネージャー）。また、ビルドシステムまたはビルドスクリプトは、インストールされたプログラムの構成を環境変数、レジストリ変数、シンボリックリンク、権限などを使用して認識している必要があることも意味します
ビルドシステムには、インストール可能なプログラム（.debまたは.msiなど）を出力するreleaseターゲットがあり、オペレーティングシステムにそのプログラムのインストールを依頼してください。また、ユーザーがmake uninstallを入力しなくてもアンインストールできるようになります。
だから、私の質問：なぜビルドシステムは通常installターゲットを推奨するのですか？
多くのビルドスクリプトまたはMakefileは、パッケージマネージャーが存在する前に作成されたため、および今日でも多くのシステムにパッケージマネージャーがないため、インストールターゲットがあります。さらに、make install実際にはisパッケージを管理するための好ましい方法です。
makefileにはinstallターゲットがない可能性があり、さらに重要なのは、インストール可能であるとさえ想定されていないプログラムがある可能性があることです（たとえば、ビルドディレクトリから実行する必要があるため、または実行できるため）どこにでもインストールできます）。 installターゲットは、通常のmakefile- sの単なるconventionです。
ただし、多くのプログラムでは、外部リソースを実行する必要があります（たとえば、フォント、データベース、構成ファイルなど）。そして、それらの実行ファイルは、これらのリソースについていくつかの仮説を立てます。たとえば、bashシェルは通常、いくつかの初期化ファイルを/etc/bash.bashrcなどから読み取ります。これらのリソースは通常、ファイルシステムにあります（ hier（7） for conventionsファイル階層について）およびデフォルトのファイルパスは実行可能ファイルに組み込まれています。
システムのほとんどの実行可能ファイルで strings（1） を使用してみてください。どのファイルパスが認識されているかがわかります。
ところで、多くのGNUプログラムを使用してautoconfを実行している場合、rootでなくてもmake install DESTDIR=/tmp/destdir/を実行できます。その後、/tmp/destdir/に後で必要なファイルが入力されますパッケージ化。
FWIW、私は自分の bismon （GPLv3 +ライセンス）プログラム（私の bismon-chariot-doc.pdf レポートに記述されている）を信じる傾向があります）「インストール」できません。それを証明できるかどうか確信が持てず、そのプログラムをインストール可能にする方法を想像することはできません。
頭に浮かぶいくつかの理由があります。
- 多くのパッケージ作成ソフトウェア（たとえば Debian ビルドシステム、およびIIRC rpmなど）は、すでにビルドスクリプトからプログラムを特別なサブディレクトリに「インストール」することを期待しています。したがって、これは両方向の下位互換性によって推進されます。
- ユーザーは、
$HOMEディレクトリなどのローカルスペースにソフトウェアをインストールすることができます。すべてのパッケージマネージャーがサポートしているわけではありません。 - パッケージを持たない環境がまだあるかもしれません。
さて、アプリケーション開発者は、各ファイルがどこに行くべきかを知っている人です。彼らはそれをドキュメンテーションに残し、パッケージのメンテナにそれを読んでもらい、各パッケージのスクリプトを作成させることができます。たぶん、パッケージのメンテナがドキュメントを誤って解釈し、機能するまでスクリプトをデバッグする必要があるでしょう。これは非効率的です。アプリケーション開発者は、自分が作成したアプリケーションを適切にインストールするためのスクリプトを作成することをお勧めします。
彼は、任意の名前でインストールスクリプトを作成することも、他のスクリプトの手順の一部にすることもできます。ただし、標準のインストールコマンドmake install（パッケージマネージャより前の慣習）、パッケージを作るのは本当に簡単になりました。 Archlinuxパッケージを作成するためのPKGBUILDテンプレート を見ると、実際にパッケージ化する関数が単にmake DESTDIR="$pkgdir/" install。これはおそらく大部分のパッケージで機能しますが、少し変更を加えるだけで機能するでしょう。 make（およびautotools）が標準であるおかげで、パッケージングは非常に簡単です。
言及されていない理由の1つは、ソフトウェアの現在のバージョンを使用していない、またはソフトウェアの変更されたバージョンを使用していないことが多いことです。カスタムパッケージを作成しようとすると、作業が増えるだけでなく、現在作成および配布されているパッケージと競合する可能性があります。オープンソースコードでは、これは、使用している将来のバージョンで重大な変更が導入された場合に特に発生します。
現在バージョン2.0.1にあるオープンソースプロジェクトFOOを使用していて、バージョン1.3.0を使用しているとします。バージョン2.0.0は現在実行しているものと互換性がないため、それ以上のものを使用したくありませんが、2.0.1には必要なバグ修正が1つあります。 make installオプションを使用すると、パッケージの作成やシステムへのインストールを心配することなく、変更された1.3.0ソフトウェアをインストールできます。
Linuxディストリビューションは通常、プログラムの保守とパッケージの保守を分離しています。パッケージ生成を統合するビルドシステムは、プログラムのメンテナーにパッケージのメンテナンスも実行することを強制します。
これは通常悪い考えです。ディストリビューションには、内部の整合性を検証し、複数のターゲットプラットフォームにバイナリを提供し、システムの残りの部分とよりよく統合するために小さな変更を加え、バグを報告するユーザーに一貫したエクスペリエンスを提供するための多くのインフラストラクチャがあります。
ビルドシステムから直接パッケージを生成するには、このインフラストラクチャをすべて統合するかバイパスする必要があります。それを統合することは疑わしい利益のために多くの仕事であり、それをバイパスすることはより悪いユーザー体験を与えるでしょう。
これは、マルチパーティシステムで一般的な「フードチェーンの最上位」の問題の1つです。複数の複雑なシステムがある場合、他のすべてのシステムを調整する責任があるシステムの明確な階層が必要です。
ソフトウェアインストール管理の場合、パッケージマネージャーはこのコンポーネントであり、パッケージのビルドシステムを実行し、便利なインターフェイス（「インストール手順後のディレクトリ内のファイル」）を介して出力を取得し、パッケージを生成して準備します。リポジトリへのアップロード用。
パッケージマネージャーは、ビルドシステムとリポジトリの間の中間に位置し、両方とうまく統合するのに最適な位置にあります。
npmから利用できるJavaScriptパッケージはaptからも利用できるのはごくわずかですが、これは主にJavaScriptの人々がnpmと関連するリポジトリを決定したためですが彼らの食物連鎖のトップになることになったため、これらのパッケージをDebianパッケージとして出荷することはほぼ不可能になりました。
私のDebian開発者の帽子をかぶった状態で：オープンソースソフトウェアをリリースする場合は、パッケージングをディストリビューションのメンテナに任せてください。それはあなたと私たちの両方の多くの仕事を節約します。