基本上有两个跟踪依赖项的选项，即-M和-MM。不同之处在于-MM省略了系统标头和它们所包含的标头。
我的问题:为什么有人想使用-M ?它极大地扩展了生成的.d文件，因为一个系统头文件通常包含一个大的其他系统头文件包。此外，系统头文件不能由make构建，因此将它们作为依赖项不会产生任何好处。我能看到的唯一一点好处是-如果所需的系统头丢失- make报告丢失的头而不是gcc报告它。但这样做的好处是什么呢?
-M有什么用处。我错过什么了吗?哪些场景需要使用-M而不是-MM
大多数头文件不能通过make "构建"。它们被列为先决条件，因此，如果它们发生变化，那么依赖于它们的源代码将被重新构建。例如，如果您在系统上安装了安全修复程序包，并且它们修改了您使用的一个系统头文件，那么您可能希望确保重新构建了所有代码。现在大多数基本库的向后兼容性是这样的，大多数时候都不需要这样做，我同意。
同样，如果你正在交叉编译，那么你的"系统"头文件将从交叉目标提供给你;这些头文件可能用于嵌入式系统或类似的系统，并且可能比标准系统更频繁地更改(以非向后兼容的方式)。
为什么会有人想要使用-M?
如果系统标头改变，您希望重新构建相应的操作。也就是说，如果你的代码使用了一个头文件，而这个头文件改变了，那么即使你的代码没有改变，你的代码也应该重新构建。
将头文件列为依赖项很少是关于"构建"这些头文件。
可能有很多原因。
在系统库更新后只重建必要的部分。难得的东西，但有人可能需要它。
获得完整的依赖关系列表，出于某些原因-也许只是绘制依赖关系图?
为所有可能使用的头文件生成ctags。
…
我个人把它用在标签上，所以它不全是假设的例子。