基本上有两个选项用于跟踪依赖关系，它们是-M 和-MM。区别在于-MM省略了系统头和它们包含的头。
我的问题：为什么有人要使用-M？它极大地膨胀了生成的.d 文件，因为系统头文件通常包含大量其他系统头文件。此外，make 无法构建系统头文件，因此将它们作为依赖项没有任何好处。我能看到的唯一一点好处是 - 如果缺少所需的系统标头 - make 报告缺少的标头而不是 gcc 报告它。但是这样做有什么好处呢？
总而言之，我认为-M 没有任何用处的理由。我错过了什么吗？有哪些场景需要使用-M 而不是-MM。
【问题讨论】：
标签： c++ c gcc makefile dependency-management
大多数头文件不能由 make “构建”。它们被列为先决条件，因此如果它们发生变化，则依赖它们的源代码将被重建。例如，如果您在系统上安装了安全修复包，并且它们修改了您使用的系统头文件之一，您可能希望确保重新构建所有代码。这些天来，大多数基础库的向后兼容性使得大部分时间都不需要这样做，我同意。
此外，如果您正在交叉编译，那么您的“系统”头文件会从交叉目标中提供给您；这些标头可能用于嵌入式系统或类似系统，并且可能比标准系统更频繁地更改（以非向后兼容的方式）。
【讨论】：
为什么有人要使用 -M？
如果系统标头发生更改，您需要相应地进行重建。也就是说，如果您的代码使用了标头，并且该标头发生了更改，那么即使您的代码没有更改，您的代码也应该重新构建。
将标头列为依赖项很少涉及“构建”这些标头。系统标头也不例外。
【讨论】：
可能有很多原因。
系统库更新后仅重建必要的部分。很少见，但有人可能需要它。
获取完整的依赖关系列表，出于某些原因 - 可能只是绘制依赖关系图？
为所有可能使用的头文件生成ctags。
...
我个人将它用于 ctags，因此并非所有假设示例。
【讨论】：