自動的に依存関係をインストールできますか？

これはmakefileの目的ではありません。 Makefileは、ソフトウェアの構築とそれを通常の方法で（パッケージマネージャなしで）システムにインストールする作業のみを処理します。実際にアプリケーションを実行するための要件が​​あるかどうかは関係ありません（注意してはいけません）。これは意図的に設計されています。いくつか考えてみましょう。

1）ディストリビューションがパッケージマネージャを使用している場合（ほぼすべてのディストリビューションが何らかの方法でこれを実行する場合）、make installパッケージマネージャをバイパスしてシステムを汚染するので、それを直接呼び出すべきではありません。この場合、make install「サンドボックス」環境で呼び出されるパッケージをビルドするとインストール内容がパッケージ化され、そのパッケージは選択したパッケージマネージャによってインストールおよび処理されます。

2）すべてを「正しい」順序でインストールする必要があるという要件はありません。実際、これは循環の依存関係を引き起こし、設置が不可能になります。パッケージマネージャでさえ、これが厳しすぎる場合が多く、問題が発生する可能性があります。また、パッケージをビルドするとき（ビルドスクリプトを呼び出すmake install）、実際にプログラムを実行する意図がなく、とにかくインストール要件がない可能性があります。結局のところ、他のコンピュータにインストールされるパッケージを作成するだけです。

3）これを行うための移植可能な方法はありません。あなたの定義はプラットフォームに依存しません。要件をどこで見つけることができるかどうかはどうすればmake installわかりますか？予期しない将来の可能性を含むすべての可能性に対処する必要があるため、パッケージマネージャを通過できず、バージョンの変更もあります。

4）何をインストールするかについての単一の決定はありません。共有ライブラリはさまざまなパッケージで利用できます。 1つ以上libc。 OpenGL機能（さまざまなグラフィックカード）、さまざまなマトリックス代数パッケージ、さまざまなメディア再生ライブラリ（vlc対gstreamer）を提供するパッケージが複数あるため、長年にわたって使用できます。システムの設計方法と使用するコンポーネントを選択できます。これがこのモジュラー設計の利点です（すべてを1つのCD / DVDに挿入し、各ライブラリが異なるパッケージを通過させる従来のWindows方式とは異なります）。各アプリケーションはギガバイト単位でインストールされ、合理的な設計に応じて10MBを超えてはいけません。）

5）これは仕事ではなく、make install異なるレベルのメンテナンスです。configure && make && make installハンドラは、インストールされているエントリ（ビルド時の依存関係）を確認し、コードをコンパイルし、ファイルを配置する場所を表示します。他の必要なソフトウェアバージョンの要件は、別々のプロセスであるパッケージングと展開領域に属します。つまり、パッケージマネージャまたは従来の方法でインストールする場合はシステム管理者です。これら2つの概念を混同しないでください。混乱を招く可能性があります。アイテムが明確に定義されたレイヤーに分割されている場合、開発者はパッケージやディストリビューションのメンテナンス担当者とは無関係にアイテムを変更できます。ディストリビューションで、アイテムを別の名前で再パッケージ化し、別の選択肢を使用することを決定し、アイテムを別のディレクトリに配置する場合は、アプリケーション開発者に頼ることはできません。 makefileがこれを知って関心を持つ責任があります。

簡単に言えば、依存関係がビルドタイム依存関係（これなしではmake実行できません - 通常はスクリプトとして検出されますconfigure）かランタイム依存関係かは、makefileレベルで実行しないでください。間違った方法で作業しないで、標準を考慮してください。まだパッケージがない作業をしている場合（ユーザーが提供したパッケージを確認してください。すでに存在する可能性があります）、必要なものを調べて実際にパッケージを構築する必要があります。これにより、パッケージを作成できる他の人にも最適です。あなたが作ったパッケージをお楽しみください。