GNU Autotools 简介

如果你还没有使用过 Autotools，本教程将改变你交付代码的方式。

图片来源：

亚历克斯·桑切斯。CC BY-SA 4.0。

你有没有下载过一个流行的软件项目的源代码，需要你输入几乎仪式化的./configure; make && make install命令序列来构建和安装它？如果是这样，你就使用过GNU Autotools。如果你曾经查看过此类项目附带的一些文件，你可能也会对此类构建系统的明显复杂性感到恐惧。

好消息！GNU Autotools 的设置比你想象的要简单得多，而且是 GNU Autotools 本身为你生成那些 1,000 行的配置文件。是的，你可以编写 20 或 30 行安装代码并免费获取另外 4,000 行。

工作中的自动工具

​如果你是 Linux 的新用户，正在寻找有关如何安装应用程序的信息，则不必阅读本文！如果你想知道研究软件是如何构建的，欢迎你阅读它，但如果你只是安装一个新应用程序，请阅读我关于在 Linux上安装应用程序的文章。

跳到内容  

对于开发人员来说，Autotools 是一种管理和打包源代码的快捷方式，因此用户可以编译和安装软件。Autotools 还受到主要打包格式（如 DEB 和 RPM）的良好支持，因此软件存储库的维护人员可以轻松准备使用 Autotools 构建的项目。

Autotools 分阶段工作：

1. 首先，在./configure步骤中，Autotools 扫描主机系统（运行它的计算机）以发现默认设置。默认设置包括支持库所在的位置，以及新软件应放置在系统中的位置。
2. 接下来，在make步骤中，Autotools 构建应用程序，通常是将人类可读的源代码转换为机器语言。
3. 最后，在make install步骤中，Autotools 将其构建的文件复制到计算机上的适当位置（在配置阶段检测到）。

这个过程看似简单，确实也很简单，只要你使用Autotools。

Autotools 的优势

GNU Autotools 是一个我们大多数人都认为理所当然的大而重要的软件。与GCC（GNU 编译器集合）一起，Autotools 是允许构建自由软件并将其安装到正在运行的系统的脚手架。如果你运行的是POSIX系统，那么毫不夸张地说，由于这些项目，你的大部分操作系统都以可运行软件的形式存在于你的计算机上。

如果你的小项目不是操作系统，你可能会认为 Autotools 无法满足你的需求。但是，尽管 Autotools 享有盛誉，但它有许多可能对你有益的小功能，即使你的项目是一个相对简单的应用程序或一系列脚本也是如此。

可移植性

首先，Autotools 考虑到了可移植性。虽然它不能使你的项目在所有 POSIX 平台上工作（这取决于你作为编码人员），但 Autotools 可以确保你标记为安装的文件安装到已知平台上最合理的位置。并且由于 Autotools，对于高级用户来说，根据他们自己的系统自定义和覆盖任何非最佳值是微不足道的。

使用 Autotools，你只需知道需要将哪些文件安装到一般位置即可。它会处理其他一切。不再有在任何未经测试的操作系统上中断的自定义安装脚本。

打包

Autotools 也得到了很好的支持。将带有 Autotools 的项目交给发行版打包器，无论他们是打包 RPM、DEB、TGZ 还是其他任何东西，他们的工作都很简单。打包工具知道 Autotools，因此可能不需要打补丁、破解或调整。在许多情况下，将 Autotools 项目合并到管道中甚至可以实现自动化。

如何使用自动工具

要使用 Autotools，你必须先安装 Autotools。你的发行版可能会提供一个旨在帮助开发人员构建项目的包，或者它可能会为每个组件提供单独的包，因此你可能需要在你的平台上进行一些研究以发现你需要安装哪些包。

Autotools 的主要组件是：

• automake
• autoconf
• make

虽然你可能需要安装项目所需的编译器（例如 GCC），但 Autotools 可以很好地处理不需要编译的脚本或binary assets。事实上，Autotools 对此类项目很有用，因为它提供了一个make uninstall脚本以便轻松删除。

安装完所有组件后，就可以查看项目文件的结构了。

Autotools项目结构

GNU Autotools 有非常具体的期望，如果你经常下载和构建源代码，他们中的大多数可能都很熟悉。首先，源代码本身应该位于名为src的子目录中。

你的项目不必遵循所有这些期望，但如果你将文件放在非标准位置（从 Autotools 的角度来看），那么你稍后必须在 Makefile 中对此进行调整。

此外，还需要这些文件：

• NEWS
• README
• AUTHORS
• ChangeLog

你不必主动使用这些文件，它们可以是包含所有这些信息的整体文档（如README.md）的符号链接，但它们必须存在。

自动工具配置

在项目的根目录中创建一个名为configure.ac的文件。autoconf使用此文件来创建用户在构建之前运行的配置shell 脚本。该文件必须至少包含AC_INIT和AC_OUTPUT M4 macros。你无需了解任何有关 M4 语言的知识即可使用这些宏；它们已经为你编写，所有与 Autotools 相关的都在文档中定义。

在你喜欢的文本编辑器中打开该文件。AC_INIT宏可能包含包名称、版本、错误报告的电子邮件地址、项目 URL 以及可选的源 TAR 文件的名称。

AC_OUTPUT macro 更简单并且不接受任何参数。

AC_INIT([penguin], [2019.3.6], [seth@example.com])
AC_OUTPUT

如果你此时运行autoconf ，将从你的configure.ac文件生成一个配置脚本，并且它会成功运行。不过，这就是它要做的全部，因为到目前为止你所做的只是定义项目的元数据并调用创建配置脚本。

你必须在configure.ac文件中调用的下一个宏是创建Makefile 的函数。Makefile 告诉make命令要做什么（通常是如何编译和链接程序）。

创建 Makefile 的宏是AM_INIT_AUTOMAKE和AC_CONFIG_FILES ，前者不接受任何参数，后者接受你要调用输出文件的名称。

最后，你必须添加一个宏来说明你的项目需要的编译器。你使用的宏显然取决于你的项目。如果你的项目是用 C++ 编写的，则相应的宏是AC_PROG_CXX，而用 C 编写的项目需要AC_PROG_CC，等等，如Autoconf 文档中的构建程序和库部分所述。

例如，我可能会为我的 C++ 程序添加以下内容：

AC_INIT([penguin], [2019.3.6], [seth@example.com])
AC_OUTPUT
AM_INIT_AUTOMAKE
AC_CONFIG_FILES([Makefile])
AC_PROG_CXX

保存文件。是时候转到 Makefile 了。

Autotools Makefile 生成

手动编写Makefile 并不难，但 Autotools 可以为你编写一个，它生成的文件将使用在该步骤中检测到的配置选项./configure，并且它包含的选项比你想象的要包含或想自己编写的要多得多. 但是，Autotools 无法检测你的项目构建所需的所有内容，因此你必须在文件Makefile.am中添加一些详细信息，而automake在构建 Makefile 时又会使用该文件。

Makefile.am使用与 Makefile 相同的语法，因此如果你曾经从头编写过 Makefile，那么这个过程将会很熟悉且简单。通常，一个Makefile.am文件只需要几个变量定义来指示要构建哪些文件，以及它们要安装到哪里。

以_PROGRAMS结尾的变量标识要构建的代码（这通常被认为是主要目标；这是 Makefile 存在的主要原因）。Automake 识别其他主要元素，如_SCRIPTS、_DATA、_LIBRARIES和构成软件项目的其他公共部分。

如果你的应用程序在构建过程中按字面意思进行了编译，那么你可以使用bin_PROGRAMS变量将其标识为二进制程序，然后引用构建它所需的源代码的任何部分（这些部分可能是一个或多个要编译的文件和链接在一起）使用程序名称作为变量前缀：

bin_PROGRAMS = penguin
penguin_SOURCES = penguin.cpp

bin_PROGRAMS的目标安装到 bindir 中，用户可在编译期间对其进行配置。

如果你的应用程序实际上并未编译，那么你的项目根本不需要bin_PROGRAMS变量。例如，如果你的项目是用 Bash、Perl 或类似解释语言编写的脚本，则定义一个_SCRIPTS变量：

bin_SCRIPTS = bin/penguin

Automake 期望源代码位于名为src的目录中，因此如果你的项目为其布局使用替代目录结构，则必须告诉 Automake 接受来自外部源的代码：

AUTOMAKE_OPTIONS = foreign subdir-objects

最后，你​​​​​​​可以在Makefile.am中创建任何自定义 Makefile 规则，它们将被逐字复制到生成的 Makefile 中。例如，如果你知道在安装继续之前需要替换源代码中的临时值，你可以为该过程制定自定义规则：

all-am: penguin
        touch bin/penguin.sh
       
penguin: bin/penguin.sh
        @sed "s|__datadir__|@datadir@|" $< >bin/$@

一个特别有用的技巧是至少在开发期间扩展现有的干净目标。make clean命令通常会删除所有生成的构建文件，但 Automake 基础结构除外。之所以这样设计，是因为大多数用户很少希望make clean删除使构建代码变得容易的文件。

但是，在开发过程中，你可能需要一种方法来可靠地将项目返回到相对不受 Autotools 影响的状态。在这种情况下，你可能需要添加以下内容：

clean-local:
        @rm config.status configure config.log
        @rm Makefile
        @rm -r autom4te.cache/
        @rm aclocal.m4
        @rm compile install-sh missing Makefile.in

这里有很大的灵活性，如果你还不熟悉 Makefile，可能很难知道你的Makefile.am需要什么。最基本的必要是一个主要目标，无论是二进制程序还是脚本，以及源代码所在位置的指示（无论是通过 _SOURCES 变量还是使用 AUTOMAKE_OPTIONS 告诉Automake在何处查找源代码）。

定义了这些变量和设置后，你可以尝试生成构建脚本，如你在下一节中所见，并调整任何缺失的内容。

Autotools 构建脚本生成

你已经构建了基础架构，现在是时候让 Autotools 做它最擅长的事情了：自动化你的项目工具。开发人员（你）与 Autotools 交互的方式与用户构建你的代码的方式不同。

构建器通常使用这个众所周知的序列：

$ ./configure
$ make
$ sudo make install

但是，要使该咒语起作用，你作为开发人员必须引导构建基础架构。首先，运行autoreconf以生成用户在运行make之前调用的配置脚本。使用–install选项引入辅助文件，例如depcomp的符号链接、在编译过程中生成依赖项的脚本、编译脚本的副本、编译器用于解释语法差异的包装器等。

$ autoreconf --install
configure.ac:3: installing './compile'
configure.ac:2: installing './install-sh'
configure.ac:2: installing './missing'

使用此开发构建环境，你可以创建用于源代码分发的包：

$ make dist

dist目标是你从 Autotools“免费”获得的规则。

这是一个内置到 Makefile 中的功能，该 Makefile 是从你简陋的Makefile.am配置生成的。该目标生成一个包含所有源代码和所有基本 Autotools 基础结构的tar.gz存档，以便下载包的人可以构建项目。

此时，你应该仔细检查存档的内容，以确保它包含你打算发送给用户的所有内容。当然，你还应该尝试自己构建：

$ tar --extract --file penguin-0.0.1.tar.gz
$ cd penguin-0.0.1
$ ./configure
$ make
$ DESTDIR=/tmp/penguin-test-build make install

如果构建成功，你会找到DESTDIR指定的已编译应用程序的本地副本（在本例中为/tmp/penguin-test-build）。

$ /tmp/example-test-build/usr/local/bin/example
hello world from GNU Autotools

是时候使用自动工具了

Autotools 是一个很棒的脚本集合，用于可预测和自动化的发布过程。如果你习惯使用 Python 或 Bash 构建器，这个工具集对你来说可能是新的，但它为你的项目提供的结构和适应性可能值得学习。

Autotools 也不仅仅适用于代码。Autotools 可用于构建Docbook项目、组织媒体（我将 Autotools 用于我的音乐发布）、文档项目以及任何其他可以从可定制安装目标中受益的东西。