我正在优化一个非常大的项目的一些 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更强大的功能呢？
关于：
[GNU Make] 使用哈希表来比较文件路径字符串，因此如果字符串不同，虽然它们代表同一个文件，但仍然无法使用 vpath 进行匹配。
Make 正在做大约正确的事情。检测两个对象是否相同需要依赖文件系统中的唯一 ID（例如 inode 编号），这些 ID 是操作系统和文件系统特定的。
为什么要使用两条不同的路径来引用相同的目标或先决条件？可以说，您在 Makefile 中所做的事情比 Make 依赖字符串相等性进行路径比较更糟糕。
另外，你可能误解了一些东西。该vpath指令和VPATH变量与搜索必备文件有关。
您很少，如果有的话，想要搜索目标文件作为先决条件（当然，它们是构建可执行文件或库的先决条件）。
这是因为不能假定目标文件存在，并且您不会搜索可能不存在的东西。当您进行干净构建时，目标文件不存在。您的 Makefile必须知道它们的确切名称是什么。这是可以变化的先决条件。例如，您知道要构建foo.o（可能已经存在于以前的构建中，也可能不存在）。您不一定知道foo.o构建的源文件。是libfoo/foo.c还是utils/foo.c？这是要vpath解决的问题：它将搜索那些地方并找到foo.c，类似于如何PATH帮助您的 shellfoo在/binor/usr/bin等中查找程序。
VPATH/vpath为小型项目编写快速而肮脏的makefile有点像hack，这些项目不会扩展到大型配置。试图改进它们是没有意义的。