“g++ -MMD”是否比包含扫描更好？答案

【问题标题】：Is "g++ -MMD" better than include scanning?“g++ -MMD”是否比包含扫描更好？
【发布时间】：2012-08-19 19:48:47
【问题描述】：

在查看构建系统时，其中很多（SCons、bjam、cmake、Tundra 等）都有内置的#include 扫描器。然而 gcc 和 icc 提供了一个 -MMD（或 -MD）选项，它输出 C++ 文件所依赖的头文件的名称。

-MMD 依赖选项似乎是可靠的。如果将#include 添加到 C 文件中，它的时间戳会改变，因此构建系统会重新编译它。如果在头文件中添加#include，它的时间戳会改变，并且会重新编译所有受影响的 C 文件。

包括扫描系统中断，但-MMD 在我看来是健壮的。哪个最好，为什么？

【问题讨论】：

【解决方案1】：

-MMD 是最好的，因为你给出的原因等等。

让编译器在正常编译过程中输出依赖项可确保完全相同的编译器选项集（例如 -I 路径和宏）在编译和查找依赖项时生效。与确保为两个单独的工具使用相同的选项相比，这减少了冗余且不易出错。

【讨论】：

谢谢。你知道为什么所有这些工具都有#include 扫描功能吗？
不是每个人都使用 gcc（或 icc），IIRC 旧版本的 gcc 仅在 -MD 的输出中包含文件名，而不是完整路径名，例如foo.o: 而不是 dir1/dir2/foo.o
MMD 包含列表的一个小问题：当您 #include 时，它会查看所有 -I 包含目录。如果有两个 foo.h 文件，它会读取第一个。因此，如果您在搜索列表前面的 -I 包含目录中添加一个具有相同名称的新头文件，则依赖 -MMD 将会中断。
@underscore_d 不管是谁的错：使用-M是个陷阱，这里值得一提。
我不明白使用-M 是一个陷阱，而不是在makefile 中列出先决条件头文件根本。如果您手动在 makefile 中列出标题先决条件，您会不会遇到完全相同的问题？添加第二个<foo.h> 可能会完全破坏你的编译，如果它没有那么使用-MMD 不会“破坏”任何东西，它只是意味着先决条件不正确，直到编译器再次在源文件上运行.