基本上有两种跟踪依赖关系的选项，-M和-MM。区别在于-MM省略了它们包含的系统标题和标题。GCC依赖项跟踪：是-M比-MM更好吗？
我的问题：为什么会有人想要使用-M？它大大增加了生成的.d文件，因为系统标题通常包含大量其他系统标题。另外，系统头文件不能由make构建，因此将它们作为依赖关系不会产生任何好处。我可以看到的唯一小好处是 - 如果缺少必需的系统标题 - make报告丢失的标题而不是gcc报告它。但是这有什么好处呢？
总结一下，我看不到为什么-M完全有用。我错过了什么吗？哪些场景需要使用-M而不是-MM。
大多数头文件不能由make构建。它们被列为先决条件，因此如果它们发生更改，那么依赖于它们的源代码将被重建。例如，如果您在系统上安装了安全修补程序软件包，并且他们修改了您使用的某个系统头文件，则可能需要确保所有代码都已重建。现在，大多数基础库的后向兼容性是这样的，大多数时候这并不是真正需要的，我同意。另外，如果你正在交叉编译，那么你的“系统”头文件是从交叉目标提供给你的;这些头文件可能适用于嵌入式系统或类似的文件，并且可能比标准系统更频繁地（以非向后兼容的方式）更改。
可能有多种原因。
系统库更新后只重建必要的零件。罕见的事情，但有人可能需要它。
获取完整的依赖关系列表，出于某种原因 - 可能只是绘制依赖关系图？
为所有可能使用的头文件生成ctags。
...
我个人使用它CTAGS，所以不是所有的假设的例子。
为什么会有人想用-M？
如果系统标题发生变化，您希望重建进行相应的操作。也就是说，如果你的代码使用了一个头文件，并且这个头文件发生了变化，即使你的代码没有改变，你的代码也应该重建。
作为依赖关系列出标题很少关于'构建'这些标题。系统头文件没有不同。