GCC 依赖跟踪：-M 是不是优于 -MM？

Posted 2023-02-22

【中文标题】GCC 依赖跟踪：-M 是不是优于 -MM？

【英文标题】：GCC Dependency Tracking: Is -M better than -MM?GCC 依赖跟踪：-M 是否优于 -MM？

【发布时间】：2014-03-24 18:03:59

【问题描述】：

基本上有两个选项用于跟踪依赖关系，它们是-M 和-MM。区别在于-MM省略了系统头和它们包含的头。

我的问题：为什么有人要使用-M？它极大地膨胀了生成的.d 文件，因为系统头文件通常包含大量其他系统头文件。此外，make 无法构建系统头文件，因此将它们作为依赖项没有任何好处。我能看到的唯一一点好处是 - 如果缺少所需的系统标头 - make 报告缺少的标头而不是 gcc 报告它。但是这样做有什么好处呢？

总而言之，我认为-M 没有任何用处的理由。我错过了什么吗？有哪些场景需要使用-M 而不是-MM。

【参考方案1】：

大多数头文件不能由 make “构建”。它们被列为先决条件，因此如果它们发生变化，则依赖它们的源代码将被重建。例如，如果您在系统上安装了安全修复包，并且它们修改了您使用的系统头文件之一，您可能希望确保重新构建所有代码。这些天来，大多数基础库的向后兼容性使得大部分时间都不需要这样做，我同意。

此外，如果您正在交叉编译，那么您的“系统”头文件会从交叉目标中提供给您；这些标头可能用于嵌入式系统或类似系统，并且可能比标准系统更频繁地更改（以非向后兼容的方式）。

【参考方案2】：

为什么有人要使用 -M？

如果系统标头发生更改，您需要相应地进行重建。也就是说，如果您的代码使用了标头，并且该标头发生了更改，那么即使您的代码没有更改，您的代码也应该重新构建。

将标头列为依赖项很少涉及“构建”这些标头。系统标头也不例外。

【参考方案3】：

可能有很多原因。

系统库更新后仅重建必要的部分。很少见，但有人可能需要它。

获取完整的依赖关系列表，出于某些原因 - 可能只是绘制依赖关系图？

为所有可能使用的头文件生成ctags。

...

我个人将它用于 ctags，因此并非所有假设示例。