GCC依赖跟踪:-M比-MM好吗?

GCC Dependency Tracking: Is -M better than -MM?

本文关键字:-MM 好吗 依赖 跟踪 GCC      更新时间:2023-10-16

基本上有两个跟踪依赖项的选项,即-M-MM。不同之处在于-MM省略了系统标头和它们所包含的标头。

我的问题:为什么有人想使用-M ?它极大地扩展了生成的.d文件,因为一个系统头文件通常包含一个大的其他系统头文件包。此外,系统头文件不能由make构建,因此将它们作为依赖项不会产生任何好处。我能看到的唯一一点好处是-如果所需的系统头丢失- make报告丢失的头而不是gcc报告它。但这样做的好处是什么呢?

总而言之,我看不出-M有什么用处。我错过什么了吗?哪些场景需要使用-M而不是-MM

大多数头文件不能通过make "构建"。它们被列为先决条件,因此,如果它们发生变化,那么依赖于它们的源代码将被重新构建。例如,如果您在系统上安装了安全修复程序包,并且它们修改了您使用的一个系统头文件,那么您可能希望确保重新构建了所有代码。现在大多数基本库的向后兼容性是这样的,大多数时候都不需要这样做,我同意。

同样,如果你正在交叉编译,那么你的"系统"头文件将从交叉目标提供给你;这些头文件可能用于嵌入式系统或类似的系统,并且可能比标准系统更频繁地更改(以非向后兼容的方式)。

为什么会有人想要使用-M?

如果系统标头改变,您希望重新构建相应的操作。也就是说,如果你的代码使用了一个头文件,而这个头文件改变了,那么即使你的代码没有改变,你的代码也应该重新构建。

将头文件列为依赖项很少是关于"构建"这些头文件。

可能有很多原因。

在系统库更新后只重建必要的部分。难得的东西,但有人可能需要它。

获得完整的依赖关系列表,出于某些原因-也许只是绘制依赖关系图?

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

我个人把它用在标签上,所以它不全是假设的例子。