是“g ++ -MMD”比包含扫描更好？ [英] Is "g++ -MMD" better than include scanning?

问题描述

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

-MMD 依赖关系选项似乎是可靠的。如果将一个 #include 添加到C文件中，其时间戳将会更改，以便构建系统重新编译它。如果你添加一个 #include 到一个头文件，它的时间戳会改变，它会重新编译所有受影响的C文件。

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

解决方案

-MMD 因为你给的原因和更多。

让编译器输出依赖作为正常编译过程的一部分，确保了一组完全相同的编译选项，例如 -I 路径和宏在编译和查找依赖时有效。与确保两个独立工具使用相同的选项相比，这种冗余性更小，并且更容易出错。

Whilst looking at build systems, a lot of them (SCons, bjam, cmake, Tundra, etc) have a built-in #include scanner. Yet gcc & icc offer a -MMD (or -MD) option which outputs the names of the header files that the C++ file depends upon.

The -MMD dependency option seems to be reliable. If you add a #include to a C file, its timestamp would change so the build system would recompile it. If you add a #include to a header file, its timestamp would change and it would recompile all affected C files.

Include scanning systems break, but -MMD would seem to me to be robust. Which is best, and why?

解决方案

-MMD is best, for the reasons you give and more.

Getting the compiler to output dependencies as part of the normal compilation process ensures that the exact same set of compiler options such as -I paths and macros are in effect for compilation and when finding dependencies. That's less redundant and less error-prone than ensuring the same options are used for two separate tools.

这篇关于是“g ++ -MMD”比包含扫描更好？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！