0

主に純粋な Makefile に基づくビルド システムをいじって、ビルド プロセスで必要な各外部ツールの存在のテストと内部変数の設定を簡単にするために、次のマクロにたどり着きました。

define tool-available
    $(eval $(1) := $(shell which $(2)))
    $(if $($(1)),$(info $(2) available at $($(1))),$(error error: missing tool $(2)))
endef

$(eval $(call tool-available,DOT,dot))
$(eval $(call tool-available,RBIN,R))
$(eval $(call tool-available,FIND,find))

ただし、サードパーティのビルドシステムは通常、外部の構成スクリプトと代替メカ​​ニズムを優先するため、メイクファイル内でこれを行うことは一般的ではないことが経験からわかっています。

which(1) プログラムはプラットフォームでの利用が制限されているという事実以外に、Makefile にそうしない強い理由はありますか?

4

1 に答える 1

0

お使いのシステムでツールが利用可能であることを明示的に確認する価値があるかどうかは、完全にはわかりません。プログラムがパスに存在しない場合、「コマンドが見つかりません」というエラーで失敗しますが、これはかなり明白です。

一方、ライブラリの存在を確認することは、付加価値があると感じています。ライブラリが欠落している場合、「ファイルが見つかりません」というメッセージが表示され、それがどのライブラリからのものであるかは示されませんが、その場合でも、ビルド環境の構成方法に関する明確なドキュメントがあればよいでしょう。実際には、奇妙な構成のシステムのすべてのエッジ ケースを処理しようとするよりも、「これを構築するために必要なものはこれだ」と言う方がはるかに簡単です。

この点に関して、私の見解は非常に好戦的であることに注意してください。誰かが README または BUILDING の指示を読んで環境を適切にセットアップする機知を持っていない場合、おそらくそもそもそれを構築しようとするビジネスはありません.ライン ：）

于 2014-02-02T01:44:59.427 に答える