为什么GNU make的vpath命令如此弱？

Question

我正在优化一个非常大的项目的一些makefile,我发现GNU make的vpath命令只能做非常有限的工作.例如:

vpath %.o $(OBJPATH)

表示通过OBJPATH搜索路径值中的所有目标文件.这意味着/dir1/../dir2/obj1.o并且/dir3/../dir2/obj1.o是相同的文件,但是,如果我已经做了/dir1/../dir2/obj1.o,当工具思考规则时/dir3/../dir2/obj1.o,它仍然无法找到它,并且必须重新制作/dir3/../dir2/obj1.o,即使它代表相同的文件/dir1/../dir2/obj1.o.

我检查了GNU make源代码; 它使用哈希表来比较文件路径字符串,因此如果字符串不同,虽然它们代表相同的文件,但它们仍然无法匹配使用vpath.

为什么不用vpath更强大的功能实现？

Answer 1

回覆:

[GNU Make]使用哈希表来比较文件路径字符串,因此如果字符串不同,虽然它们代表相同的文件,但仍然无法使用vpath进行匹配.

Make正在做大致正确的事情.检测两个对象是否相同需要依赖于文件系统中的唯一ID(例如inode编号),这些ID是OS和特定于文件系统的.

为什么使用两个不同的路径来引用相同的目标或先决条件？可以说,你在Makefile中所做的比使用依赖字符串相等进行路径比较更糟糕.

另外,你可能会误解某些东西.该vpath指令和VPATH变量都涉及到搜索必备文件.

您很少(如果有的话)希望将对象文件作为先决条件进行搜索(即使它们是构建可执行文件或库的先决条件).

这是因为不能假定目标文件存在,并且您不搜索可能不存在的内容.执行干净构建时,目标文件不存在.你的Makefile 必须知道它们的确切名称.这是可以变化的先决条件.例如,您知道要构建foo.o(可能已经存在于以前的构建中,或者可能不存在).你不一定知道的foo.o是构建它的源文件.难道libfoo/foo.c还是utils/foo.c？这是一个问题vpath解决了:它会搜索那些地方找到foo.c,类似于如何PATH帮助你的shell查找程序foo中/bin或/usr/bin等

VPATH/vpath对于为小型项目编写快速和脏的makefile而言,它们有点骇人听闻,它们无法扩展到大型配置.尝试改进它们毫无意义.