automake - 为什么 automake 和 autotools 没有失去 GNU Make 的力量？

Question

我对 GNU Make 非常有经验，但对 autotools 完全陌生。通过查看一些教程，我了解到 autotools 是一种标准化 makefile 目标并跨多个体系结构构建的方法。这是一件好事，因此开源发行版的用户可以始终以相同的方式构建和安装它们。

GNU Make 非常强大和灵活:任何 shell 命令都可以用来构建目标，目标对先决条件的依赖可以用许多高效和灵活的方式表达。

是否可以通过将 Makefile 转换为 Makefile.am 将 Makefile 的所有功能转移到基于 automake 的系统？我在教程中找到了以下语句:

像这样的规则

%.foo: %.bar

不可移植，不能在 Makefile.am 中使用。因此，程序员必须在模式规则足够的地方编写显式规则，这肯定更耗时且更难维护。

此外，在我见过的示例 Makefile.am 文件中，我从未见过任何复杂的变量计算或函数。

那么，如果 automake 限制了 GNU Make 的构造，它又如何能够以与 GNU Make 相同的效率、编程速度和可维护性来构建相同的软件呢？

我假设它可以，我只是没有看到明显的东西。

Answer 1

我不是很精通，也不是 autotools 的忠实粉丝，但我的理解是这样的:

autotools 的目的是提高可移植性，例如对于没有 GNU Make 的系统。示例包括 HP-UX、Solaris、IRIX 和 BSD 系列。 autotools 用户可以使用始终不变的指令序列构建程序:

./configure
make

这里，./configure 是一个/bin/sh 脚本，它在开发人员的系统上生成并且是可移植的，因此它可以在广泛的系统上运行。生成的 Makefile 是特定于平台的，包括对特定于平台的要求/问题的处理。此外，./configure 生成一个 config.h 文件，该文件允许 C 代码对某些库的可用性/不存在使用react，以构建传递给 ./configure 的选项。

GNU build system 上的维基百科页面包括整个过程中涉及的文件的漂亮图表:

configure 和Makefile.in 之前的所有内容都是在开发者系统上预先生成的，config.status 及以下是在开发者系统上生成的构建(用户)系统。

今天的自动工具有什么相关性？显然，它们仍在许多项目中使用。然而，非 Linux UNIX 操作系统的重要性已大大下降。那些仍然存在的都可以使用 GNU Make。正如您所说，GNU Make 具有数量惊人的功能，并且可以非常轻松地编写自动跟踪依赖项并处理可用/缺失库的 Makefile。

因此，我个人所有的 make 系统都是基于 GNU Make 编写的，我很高兴我已经多年不用接触自动工具了。