makefileには、すべてのオブジェクトとライブラリファイルをリンクして実行可能ファイル(.elfファイル)を作成するレシピが1つあります。副作用として、このステップは、マップファイルとIntelの.hexファイルを生成します:複数のターゲットを作成するレシピ
$(ELF_FILE) : <list of dependencies here>
<linker command line>
今まで、私たちは実際に今までに別のターゲットのいずれかに依存$(MAP_FILE)
または$(HEX_FILE)
ターゲットを、持っていなかったので、 $(ELF_FILE)
のサイドプロダクトは、そのターゲットのレシピが$(ELF_FILE)
にアクセスしたくないとしても、単にそれが$(ELF_FILE)
に依存すると宣言しました。例えば:この新しい発見の知識を用いて
$(MAP_FILE) $(HEX_FILE) $(ELF_FILE) : <list of dependencies here>
<linker command line>
、我々は取り除くことができ考え出し:
# Target that needs map-file, which is a side product of the $(ELF_FILE) target.
$(TARGET_THAT_NEEDS_MAP_FILE) : $(ELF_FILE)
<build-recipe>
# Target that needs hex-file, which is also a side product of the $(ELF_FILE) target.
$(TARGET_THAT_NEEDS_HEX_FILE) : $(ELF_FILE)
<build-recipe>
我々はそうは次のようにレシピは、複数のターゲットのために使用することができることが最近判明しています
$(TARGET_THAT_NEEDS_MAP_FILE) : $(MAP_FILE)
<build-recipe>
$(TARGET_THAT_NEEDS_HEX_FILE) : $(HEX_FILE)
<build-recipe>
これらの変更を実装した、我々は今、私たちはどちらかの目を誤解してきたことを疑うになり奇妙な効果を観察する:「ハック」とだけ直接各ターゲットの直接の依存関係を述べる上記のmake
という複数ターゲットのレシピ機能であるか、正しく使用されていません。奇妙な効果は、.elf、.map、および.hexファイルを生成するレシピが2回実行されるように見えることです。これは直ちに問題を引き起こしたようではありませんが、ここでは何かが怪しいことを示すようです。だから私の質問は、私たちの新しいアプローチはまったく機能するのだろうか、私は上記のハックに固執すべきか?
編集:私たちはmake
をマルチスレッド方式(つまり-jを使用)で実行しています。
このメッセージの冒頭にあるあなたのコメントは正しくありません。 'foo:bar baz'のようなルールは、すべての前提条件が構築された後、そのレシピを1回実行します。各前提条件は、それが前提条件として何回表示されても、1回構築されます。問題は、これは 'foo fab:bar baz'が実際に_TWO_ルールを定義していることです。これは、makeの観点から、 'foo:bar baz'と' fab:bar baz'を別々に書くことと同じです。これは明示的なルールにのみ当てはまります。メッセージの2番目の部分に表示されるパターンルールは、別の方法で処理されます。 – MadScientist
私の定式化はあまり明確ではありませんでした。つまり、ルールは「foo:bar baz」、「bar baz:fab」(実際は2つのルール)、2番目のルール生成バー、効果は、バーのレシピが既に起動されているが、まだ終了していないことを知らずに、bazを再構築しようとする可能性があります(これはparrallelビルドのコンテキストでのみ発生します)。それは可能でしょうか? – VannTen
はい、それは実際にはかなり可能性があります。 – MadScientist