为什么不使用automake和autotools失去GNU Make的功能？

Question

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

GNU Make非常强大和灵活：任何shell命令都可用于构建目标，并且可以用许多有效且灵活的方式表达先决条件上目标的依赖关系。

通过将Makefile转换为Makefile，可以将Makefile.am的所有功能转移到基于automake的系统吗？我在教程中发现了语句，例如：

像

这样的规则

%.foo: %.bar

不可移植，无法在Makefile.am中使用。因此，程序员必须编写明确的规则，其中模式规则就足够了，这肯定更耗时且维护更少。

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

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

我认为可以，我只是看不到明显的东西。

Answer 1

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

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

./configure
make

此处，./configure是在开发人员系统上生成的/bin/sh脚本，并且是可移植的，因此可以在各种系统上运行。生成的Makefile是特定于平台的，包括处理特定于平台的要求/问题。此外，./configure生成config.h文件，该文件允许C代码对某些库的可用性/缺失做出反应，以构建传递给./configure的选项。

GNU build system上的维基百科页面包含了整个过程中涉及的文件的精美图表：

在开发人员系统上预先生成configure和Makefile.in的所有内容，config.status及以下内容都在构建（用户）系统上生成。

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

因此，我亲自编写了基于GNU Make的所有make系统，并且我很高兴我多年来不必触摸autotools。