プロジェクトで（GNU）Makeを使用しています。私は現在、ディレクトリごとに1つのmakefileを配置し、SUBDIRSを使用してサブディレクトリを指定しています。これはmakeを使用する理想的な方法ではなく、1つのトップレベルのmakeファイル（または複数の、includeを使用して分割）を使用することをお勧めします。過去にこのレイアウトを移行/使用してみましたが、不必要に複雑に見えます。
再帰的なmakefileを使用することの利点/欠点はどれですか？
11925 次
8 に答える
24
最初に覚えておくべきこと (誤解を避けるために) は、1 つの makefile と複数の makefile について話しているのではないということです。メイクファイルをサブディレクトリごとに 1 つに分割することは、どのような場合でもおそらく良い考えです。
依存関係ツリーを複数のツリーに分割するという主な理由から、再帰的なメイクファイルは良くありません。これにより、make インスタンス間の依存関係が正しく表現されなくなります。これにより、依存関係ツリー (の一部) が複数回再計算され、最終的にはパフォーマンスの問題になります (ただし、通常は大きな問題ではありません)。
特に大規模なコード ベースがある場合に、single-make アプローチを適切に使用するには、いくつかのトリックを使用する必要があります。
まず、GNU make を使用します (既に行っているようです)。GNU make には物事を単純化する多くの機能があり、互換性について心配する必要はありません。
次に、ターゲット固有の変数値を使用します。これにより、たとえば、make 全体で 1 つの CFLAGS を強制する代わりに、ターゲットごとに異なる CFLAGS の値を設定できます。
main: CFLAGS=-O2
lib: CFLAGS=-O2 -g
3 番目に、GNU make でサポートされている範囲で VPATH/vpath を使用していることを確認してください。
また、同じ名前のソース ファイルが複数存在しないようにする必要もあります。VPATH の 1 つの制限は、ターゲット固有の VPATH 定義を持つことができないため、ソース ファイルの名前は単一の「VPATH 名前空間」に共存する必要があることです。
于 2008-11-26T12:26:03.930 に答える
18
「Recursive Make Considered Harmful」というタイトルの記事は、http: //miller.emu.id.au/pmiller/books/rmch/?ref=DDiyet.Comにあります。(または、SourceForge のAegisプロジェクトで。)
再帰的なメイクファイルの問題を調査し、単一のメイクファイル アプローチを推奨します。
于 2008-11-26T06:06:43.977 に答える
7
私は再帰を広範囲に使用します。各リーフ ノードには独自の makefile があります。次のことを考慮してください。
$LIBS = libfoo libbar
$(LIBS):
cd $@ && $(MAKE)
大規模なシステムでは、この構造を持たないことは非常に困難です。「再帰的なmakeは有害と見なされる」という人々の話は、正確な評価です。それぞれの状況は少しずつ違うと思います。
于 2011-05-05T06:12:48.263 に答える
4
歩くのではなく、 cmake.org にアクセスして、最高のビルド ツールの 1 つであるCmakeを入手してください。
GNU make を引き続き使用しますが、この場合、CMake が makefile を生成します。
100% を保証することはできませんが、サブディレクトリ間の依存関係が正しく処理されていないケース (つまり、再帰的な make を悩ませる問題) にまだ遭遇していません。少なくとも、makefile よりも Cmakefile を維持する方がはるかに簡単です。強くお勧めします。
GNU autotools を使用しないでください - その方法は狂気です!
于 2008-11-26T12:46:43.373 に答える
0
私が過去に得た利点は、単一のサブディレクトリにファイルを作成する方が簡単だということです。依存関係でこれを行うことができますが、すべてのターゲットをまっすぐに保つにはもう少し手間がかかります。基本的に、これにより、より大きなプロジェクトの完全な複雑さに対処する必要なく、変更を加えて 1 つのライブラリをテストすることが容易になります。
于 2008-11-26T05:46:10.760 に答える
0
3 番目のオプションを投入するには、GNU Autotools を使用できます。主に他の理由で使用されますが、マルチディレクトリ ビルドの編成にも役立つ場合があります。
http://www.lrde.epita.fr/~adl/autotools.html
ただし、結果は再帰バージョンであることに注意する必要があります。
于 2008-11-26T06:13:24.353 に答える
0
于 2011-04-14T17:09:13.533 に答える
-1
再帰的 make の問題は、1 つの大きな make ファイルを評価する場合と比較して、すべての異なる make ファイルを評価する場合の時間のオーバーヘッドです。これの一部はプロセスを生成するだけですが、(IIRC) 他の make ファイルが何かを行ったと想定し、実際には必要のないときに再構築することを余儀なくされる傾向があります。
私の見解では、「ユニット」ごとに 1 つの make ファイルを持つことです。これは、多かれ少なかれ、それ自体で使用できると予想されるコードのチャンクごとに make ファイルを持つことになります (たとえば、独立したライブラリとして)。
私の現在のプロジェクトのOTOHは、ビルド中にmakeファイルを生成しているため、これをあちこちで壊しています。:b
于 2008-11-26T05:53:55.330 に答える