C++ 包含头的Makefile，包括头

在

app.c

中：

#include "app.h"

在

app.h

中：

#include "model/world.h"
#include "controller/controller.h"

---

如何在makefile中为

app.o

编写目标？我是否应该在前提条件中包含所有三个标题？

是的，您应该列出可能需要重新编译app.o的app.c的所有依赖项

您可能会发现g++-MM app.c很有用：-MM将以make格式列出app.c的所有依赖项。您甚至可以将其自动化，并让makefile半自动地处理依赖项

app.o : app.c app.h model/world.h controller/controller.h
    gcc -c app.c 

是的，您需要将所有三个标题都作为依赖项包括在内。Makefiles：如果

：

右侧的任何内容已更改，则需要重新制作左侧的内容。如果您修复了控制器中的一个bug，并从其中一个函数中删除了三个参数，并且应用程序从控制器调用了该函数，那么应用程序需要重新制作以处理更改

---

否则，当应用程序走到控制器前，要求使用带有5个参数的函数X时，新的和改进的控制器不会知道应用程序到底在说什么。将抛出错误。到处都是血与火。一切都以眼泪结束

否，不应将标题列为依赖项！这与已经以

#include

指令形式存在的规范是多余的。冗余迟早会导致问题，因为随着项目的发展，最终会出现不一致的列表

还有一种普遍但天真的误解，认为只有头文件是依赖项。这可能会导致错误的构建，因为许多其他原因，如更改的命令行开关、更改的编译器或更改的硬件体系结构，都会受到监督

这两个问题的解决方案都是使用可靠的构建工具：处理这些情况，甚至可以在启动时扫描甚至还没有构建的include文件中的sub-include

---

还有很多事情要做。除了做GNU make所能做的几乎所有事情外，还有许多更有用的事情，您甚至可以通过一些Perl编程来扩展make文件。

对于一个简单的程序，自动生成依赖项是一件过分的事情。命名您关心的依赖项（例如，您可能修改的一个或两个头文件）就足够了。另一方面，这里的示例建议使用多个目录中的文件构建程序，头文件包括其他头文件。手工维护这种复杂的依赖关系是痛苦的，而且容易出错。