Makefile 和具有复杂相互依赖关系的大型项目答案

【问题标题】：Makefiles and large projects with complex interdependenciesMakefile 和具有复杂相互依赖关系的大型项目
【发布时间】：2016-08-14 07:33:22
【问题描述】：

我正在尝试为具有如下结构的大型项目设计一个构建系统：

├── deploy
├── docs
├── libs
│   ├── lib1
│   └── lib2
├── scripts
└── tools
    ├── prog1
    └── prog2

我的问题是库和程序可能会以经常变化的顺序相互依赖。我在互联网上查找了信息，我收到的信息不一。有人说我应该只使用 makefile，而另一些人说递归 makefile 是邪恶的。

除此之外，我不知道如何使用 makefile 管理依赖项（如果 lib2 需要 lib1 来构建，如何告诉 make 先构建 lib1）。有人告诉我，使用变量VPATH 很容易实现，但我已经阅读了文档，我认为这与此无关。

所以我的问题是：

【问题讨论】：

是的，你应该避免使用 GNU make。工作替代品（不是最新列表）：cmake、scons 和 jam。如果你知道 Perl：pcons 2.3。如果您想坚持使用 make，那么至少使用 BSD make 代替（Linux 系统上的 pmake 或 bmake）。
“避免使用 GNU make”并选择 pmake 或 bmake 是不好的建议。如果您继续使用 make，GNU make 是最便携、使用最广泛的版本，它有一本重要的用户手册，为它编写了许多书籍，并且最容易获得帮助。当人们说“递归 makefile 是邪恶的”时，他们不一定是在说“不要使用 make”。他们说如果您使用 make 然后考虑以非递归方式编写您的 makefile。我同意 VPATH 对此没有直接帮助。
如果您不想编写自己的 makefile，那么 cmake（非常跨平台）和 automake（在 Windows 上不能很好地工作）将使用更简单的输入结构为您生成 makefile。两者都有自己的复杂性和学习曲线。 cmake 不仅可以生成 makefile：它还可以生成 Eclipse 项目文件、Xcode 项目文件、Visual Studio 项目文件以及各种其他文件。

【解决方案1】：

我并不认为递归 makefile 是邪恶的阵营——虽然递归 makefile 确实没有那么高效（它们不能最大化并发性等），但它通常可以忽略不计。另一方面，使用递归 makefile 可以让您的项目更具可扩展性 - 将模块移入和移出、与其他组共享等更简单。

在你的情况下，如果 lib2 依赖于 lib1，你可以这样做：

 lib2: lib1
    make -C libs/lib2

现在 make 将在 lib2 之前构建 lib1（即使您指定了 -j）。

现在，如果您有交叉依赖项（lib1 中的某些内容依赖于 lib2 中的某些内容，而后者又依赖于 lib1 中的其他内容），那么您可能需要考虑重组目录以避免交叉依赖关系，或者使用单个 makefile（如果您在这种情况下尝试使用递归 makefile，则会暴露出很多尖锐的棍子）。

【讨论】：

【解决方案2】：

我在不要撒谎阵营。这里，细粒度的依赖是你的朋友。不要认为您需要表达 prog1 依赖于 lib2。你真正想对 make 说的是：

“要链接 prog1，您需要所有 .o 文件和所有适当的 .a 文件。”

如果你能表达出来，它将为您的构建改进一些非常重要的参数：

毕竟，这些目标确实是使用 make 的全部意义所在。弄错了，您不妨使用批处理文件。（顺便说一句，在递归 make 系统中让它们正确是非常棘手的。）

当然，在 make 中清晰地表达这一点确实需要一些努力，但你确实说过你有一个大型项目。

【讨论】：