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