0

摆弄一个主要基于纯 Makefiles 的构建系统，我来到了以下宏，以便于测试是否存在，并为构建过程所需的每个外部工具设置一个内部变量。

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))

然而，经验表明，在 makefile 中这样做并不常见，第三方构建系统通常更喜欢外部配置脚本和替代机制。

除了 which(1) 程序在平台上的可用性有限这一事实之外，还有什么强有力的理由不将其放入 Makefile 中？

4

1 回答 1

0

我不完全确定明确检查该工具是否以您的系统可用的方式有任何价值。如果您的路径上不存在该程序，它将失败并出现“找不到命令”错误，这是非常明确的，那么为什么要浪费时间显式检查它呢？

另一方面，检查库的存在，我觉得确实增加了价值。如果缺少某个库，您可能只会得到一个“找不到文件”，而没有指明它来自哪个库，但即便如此，关于如何配置构建环境的清晰文档会更好；实际上，说“这是您构建它所需要的”比尝试处理那里配置怪异的系统的所有边缘情况要容易得多。

请注意，我的观点在这方面是相当激进的；如果有人没有智慧阅读自述文件或构建说明并适当地设置他们的环境，那么他们可能一开始就没有商业尝试来构建它......不那么愤世嫉俗的人可能想要更温和线 ：）

于 2014-02-02T01:44:59.427 回答