我正在优化一个非常大的项目的一些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 ？
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在/bin或/usr/bin中找到程序foo等 .VPATH/vpath对于为小型项目编写快速和脏的makefile而言有些骇人听闻，它们无法扩展到大型配置 . 尝试改进它们毫无意义 .