使用make时，目标文件是否应该依赖于自己的头文件？答案

【问题标题】：When using make, should an object file depend on its own header file?使用make时，目标文件是否应该依赖于自己的头文件？
【发布时间】：2013-12-15 22:14:02
【问题描述】：

问题是：对于foo.c，在较大项目的别处使用的.c文件，是否应该将Makefile中的foo.o目标文件编译目标列表foo.h作为依赖？

foo.o: foo.c foo.h
    $(CC) $(CFLAGS) -c -o foo.o foo.c

这只是约定俗成的问题吗？

这是我到目前为止的想法，也是一个答案：

似乎对foo.h 的任何合法更改都需要对foo.c 进行相应更改。因此，没有必要将foo.h 列为依赖项。但是，这可能是个好主意，因为如果更改 foo.h 破坏了 foo.c 中的任何内容，我们希望立即（通过重新编译）得到通知。

【问题讨论】：

据我所知，如果您定义规则 something.o，make 将自动构建 something.c，并以 something.h 作为依赖项，但您可以检查它。
对标头的各种更改需要重新构建源文件但不需要更改代码。例如更新 #define 或重新排序结构的成员。将标头视为依赖项允许自动重建适当的代码。
Gnu make 将隐式添加相应的.h 文件到依赖项。它是默认suffix list 的一部分。如果您不希望它成为依赖项的一部分，则必须明确覆盖此规则。
卢卡斯：那不是真的。默认规则不会自动添加标头。那将是一场灾难，因为绝对不需要每个源文件都有相应的头文件。许多人没有。
@MadScientist：您似乎是对的，标题不在默认规则中。但我认为将它们添加到默认规则中不会是灾难性的。如果.h 文件丢失，它将被忽略。您也可以添加如下规则：%.o: %.c %.h $(COMPILE.c) $(OUTPUT_OPTION) $<（%.h 之后有一个换行符，但 cmets 不会让我这样做）。

【解决方案1】：

很可能对不需要更改 .c 文件的头文件进行更改。比如改变常量的值等等。

您总是希望将源文件使用的所有头文件作为目标文件的先决条件。

【讨论】：

啊，常量的使用（正如您所指出的）是一个很好的例子，可以阐明这种情况。这就是我正在寻找的那种东西……你（或其他任何人）能想到其他人吗？
C 中的宏代替 C++ 中的内联函数。
对类型的某些更改可能不需要更改代码；例如 int 到无符号，反之亦然。在头文件中添加或删除#include 可能不需要更改代码。显然在 C++ 中有更多的机会。
我刚刚想到的另一个：重新排列结构的成员。