概念：GNU构建系统和Autotool

原文：概念：GNU构建系统和Autotool

常用Linux的开发人员或者运维人员，可能对configure->make->make install至关熟悉。事实上，这叫GNU构建系统，利用脚本和make程序在特定平台上构建软件。这种方式成为一种习惯，被普遍使用。本文从用户视角和开发者视角详细说明，这种构建方式的细节，以及开发者如何利用autoconf和automake等工具(autotools)建立兼容GNU构建系统的项目。

为了简化可移植构建的难度，在早期有一套autotools工具帮助程序员构建软件。咱们熟知的configure->make->make install三部曲，大多都是基于autotools来构建的。autotools是GNU程序的标准构建系统，因此其实咱们常常在使用三部曲。有些程序虽然也是这三部曲，但却不是用autotools实现的，好比nginx的源码就是做者本身编写的构建程序。

用户视角

用户经过configure->make->make install基于源码安装软件。然而大部分用户可能并不知道这个过程究竟作了些什么。

configure脚本是由软件开发者维护并发布给用户使用的shell脚本。这个脚本的做用是检测系统环境，最终目的是生成Makefile和config.h。

make经过读取Makefile文件，开始构建软件。而make install能够将软件安装到须要安装的位置。

如上图，开发者在分发源码包时，除了源代码(.c .h...)，还有许多用以支撑软件构建的文件和工具，其中最重要的文件就是Makefile.in和config.h.in。configure脚本执行成功后，将为每个*.in文件处理成对应的非*.in文件。

大部分状况只生成Makefile和config.h，由于Makefile用于make程序识别并构建软件，而config.h中定义的宏，有助于软件经过预编译来改变自身的代码，以适应目标平台某些特殊性。有些软件在configure阶段，还能够生成其余文件，这彻底取决于如软件自己。

configure

当运行configure时，将看到相似以下的系统检查，这些检查的多少取决于软件自己的须要，也就是由软件开发者来定义和编写的。

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
...

通常来讲，configure主要检查当前目标平台的程序、库、头文件、函数等的兼容性。这些检查结果将做用于config.h和Makefile文件的生成。从而影响最终的编译。

用户也能够经过给configure配置参数来定制软件须要包含或不须要包含的组件、安装路径等行为。这些参数分为5组，能够经过执行./configure --help来查看，软件提供哪些配置参数：

• *安装路径相关配置。最多见的是--prefix。

• *程序名配置。例如--program-suffix可用于为生成的程序添加后缀。

• *跨平台编译。不太经常使用。

• *动态库静态库选项。用于控制是否生成某种类型的库文件。

• 程序组件选项。用于配置程序是否将某种功能编译到程序中，通常形如--with-xxx。这多是最经常使用的配置，并且由软件开发者来定义。

（*表示这是几乎全部软件都支持的配置，由于这些配置是autotool生成的configure脚本默认支持的。）

configure在执行过程当中，除了生成Makefile外，还会生成的文件包括但不限于：

• config.log 日志文件

• config.cache 缓存，以提升下一次configure的速度，需经过-C来指定才会生成

• config.status 实际调用编译工具构建软件的shell脚本

若是软件经过libtool构建，还会生成libtool脚本。关于libtool脚本如何生成，请看开发者视角。

configure常常会中途出错，这通常是因为当前平台不具备构建该软件所必需的依赖（库、函数、头文件、程序...)。此时，不要慌张，仔细查看输出，解决这些依赖。

开发者视角

开发者除了编写软件自己的代码外，还须要负责生成构建软件所须要文件和工具。当我接触到autotools后，我发现，虽然有工具的帮助，但这件事情依旧十分复杂。

对于C或C++程序员，在早期，构建跨平台的应用程序是至关繁琐的一件事情，并且对于经验不足的程序员而言，甚至难度巨大。由于构建可移植的程序的必要前提是对各个平台足够了解，这每每要花上至关长的时间去积累。

Unix系统的分支复杂度很高，不一样的商用版或开源版或多或少都有差别。这些差别主要体如今：系统组件、系统调用。咱们主要将Unix分为以下几个大类：IBM-AIX HP-UX Apple-DARWIN Solaris Linux FreeBSD。Unix分支大全

所以，对于开发者而言，要么本身编写构建用的脚本，这每每须要极其扎实的shell能力和平台熟悉度。另外一个选择就是部分依赖工具。autoconf和automake就是这样的工具。

autoreconf

为了生成configure脚本和Makefile.in等文件，开发者须要建立并维护一个configure.ac文件（在早期，一般叫configure.in文件，虽然没有区别，但强烈建议使用.ac，由于.in文件每每意味着被configure脚本识别为模板文件并生成直接参与最终构建的文件，configure.in在命名上有歧义）,以及一系列的Makefile.am。autoreconf程序可以自动按照合理的顺序调用autoconf automake aclocal等程序。

configure.ac

configure.ac用于生成configure脚本。autoconf工具用来完成这一步。下面是一个configure.ac的例子：

AC_PREREQ([2.63])
AC_INIT([st], [1.0], [zhoupingtkbjb@163.com])
AC_CONFIG_SRCDIR([src/main.c])
AC_CONFIG_HEADERS([src/config.h])

AM_INIT_AUTOMAKE([foreign])


# Checks for programs.
AC_PROG_CC
AC_PROG_LIBTOOL

# Checks for libraries.

# Checks for header files.

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.

AC_CONFIG_FILES([Makefile
                 src/Makefile
                 src/a/Makefile
                 src/b/Makefile])
AC_OUTPUT

其中以AC_开头的相似函数调用同样的代码，实际是一些被称为“宏”的调用。这里的宏与C中的宏概念相似，会被替换展开。m4是一个经典的宏工具，autoconf正是构建在m4之上，能够理解为autoconf预先实现了大量的，用于检测系统可移植性的宏，这些宏在展开后就是大量的shell脚本。因此编写configure.ac须要对这些宏熟练掌握，而且合理调用。有时，甚至能够本身实现本身的宏。

autoscan和configure.scan

能够经过调用autoscan命令获得一个初始化的configure.scan文件，而后重命名为configure.ac后，在此基础上编辑configure.ac。autoscan会扫描源码，并生成一些通用的宏调用、输入的声明以及输出的声明。尽管autoscan十分方便，可是没人可以在构建以前，就把代码彻底写好，所以autoscan一般用于初始化configure.ac。

autoheader和config.h

autoheader命令扫描configure.ac中的内容，并肯定须要如何生成config.h.in。每当configure.ac有所变化，均可以经过再次执行autoheader更新config.h.in。在configure.ac经过AC_CONFIG_HEADERS([config.h])告诉autoheader应当生成config.h.in的路径。在实际的编译阶段，生成的编译命令会加上-DHAVE_CONFIG_H定义宏，因而在代码中，咱们能够经过下面代码安全的引用config.h。

/bin/sh ../../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H ...

#ifdef HAVE_CONFIG_H
#include <config.h>
#endif

config.h包含了大量的宏定义，其中包括软件包的名字等信息，程序能够直接使用这些宏；更重要的是，程序能够根据其中的对目标平台的可移植性相关的宏，经过条件编译，动态的调整编译行为。

automake和Makfile.am

手工编写Makefile是一件至关烦琐的事情，并且，若是项目复杂的话，编写难度将愈来愈大。于是，automake工具应运而生。咱们能够编写像下面这样的Makefile.am文件，并依靠automake来生成Makefile.in：

SUBDIRS = a b
bin_PROGRAMS    = st
st_SOURCES        = main.c
st_LDADD        = $(top_builddir)/src/a/liba.la $(top_builddir)/src/b/libb.la

这里经过SUBDIRS声明了两个子目录，子目录的中的构建须要靠a/Makefile.am和b/Makefile.am来进行，这样多目录组织起来就方便多了。

bin_PROGRAMS声明一个可执行文件目标，st_SOURCES指定这个目标所依赖的源代码文件。另外，st_LDADD声明了可执行文件在链接时，须要依赖的Libtool库文件。

经过这个Makefile.am文件生成的Makefile.in文件至关大，不便贴出，可是能够想象，Makefile.in要比咱们手工编写的Makefile文件复杂的多。

automake的出现晚于autoconf，因此automake是做为autoconf的扩展来实现的。经过在configure.ac中声明AM_INIT_AUTOMAKE告诉autoconf须要配置和调用automake。

aclocal

上面提到，configure.ac实际是依靠宏展开来获得configure的。所以，可否成功生成取决于，宏定义可否找到。autoconf会从自身安装路径下来寻找事先定义好了宏。然而对于像automake、libtool和gettext等第三方扩展宏，甚至是开发者自行编写的宏就一无所知了。因而，存在这个工具aclocal，将在configure.ac同一目录下生成aclocal.m4，在扫描configure.ac的过程当中，将第三方扩展和开发者本身编写的宏定义复制进去。这样，autoconf在遇到不认识的宏时，就会从aclocal.m4中查找。

下面这张图更为详细的展示了整个工具链是如何互相配合的。

libtool

libtool试图解决不一样平台下，库文件的差别。libtool实际是一个shell脚本，实际工做过程当中，调用了目标平台的cc编译器和连接器，以及给予合适的命令行参数。libtool能够单独使用，这里只介绍与autotools集成使用相关的内容。

automake支持libtool构建声明。在Makefile.am中，普通的库文件目标写做xxx_LIBRARIES：

noinst_LIBRARIES = liba.a
liba_SOURCES = ao1.c ao2.c ao3.c

而对于一个libtool目标，写做xxx_LTLIBRARIES，并以.la做为后缀声明库文件。

noinst_LTLIBRARIES = liba.la
liba_la_SOURCES = ao1.c ao2.c ao3.c

在configure.ac中须要声明LT_INIT：

...
AM_INIT_AUTOMAKE([foreign])
LT_INIT
...

有时，若是须要用到libtool中的某些宏，则推荐将这些宏copy到项目中。首先，经过AC_CONFIG_MACRO_DIR([m4])指定使用m4目录存放第三方宏；而后在最外层的Makefile.am中加入ACLOCAL_AMFLAGS = -I m4。

all-in-one

上面讨论了不少关于autoreconf的细节。实际上，现在咱们能够直接调用autoreconf --install来自动调用上面提到的全部子命令。这里--install参数试图将辅助的脚本和宏copy到当前项目目录中，下面是执行时的输出：

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal 
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoreconf: running: /usr/bin/autoconf
autoreconf: running: /usr/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
configure.ac:10: installing `./config.guess'
configure.ac:10: installing `./config.sub'
configure.ac:9: installing `./install-sh'
configure.ac:9: installing `./missing'
src/Makefile.am: installing `./depcomp'
autoreconf: Leaving directory `.'

当咱们以--install参数运行时，libtoolize --copy被调用，这将使得ltmain.sh被copy进来；接下来分别执行autoconf和autoheader；automake的参数为--add-missing --copy --no-force，这将使得几个辅助脚本和文件被安装到目录下。

这些辅助文件默认安装在configure.ac同一个目录下，若是你但愿用另外一个目录来存放他们，能够配置AC_CONFIG_AUX_DIR，例如AC_CONFIG_AUX_DIR([build-aux])将使用build-aux目录来存放辅助文件。

若是不使用--install参数，辅助文件要么不copy，要么以软链的形式建立。推荐使用--install，由于这样，其余软件维护能够避免因为构建工具版本不一致形成问题。

辅助文件

一个依靠GNU构建系统开发的软件除了源码以外，还有不少辅助的文件，有些是脚本，有些是文本文件。下面将逐一解释这些文件：

• aclocal.m4：上面提到了，这个宏定义文件里面包含了第三方的宏定义，用于autoconf展开configure.ac

• NEWS README AUTHORS ChangeLog：这些文件是GNU软件的标配，不过在项目中不必定须要加入。若是项目中没有这些文件，每次autoreconf会提示缺乏文件，不过这并不影响。若是不想看到这些错误提示，能够用AM_INIT_AUTOMAKE([foreign])来配置automake。foreign参数就是告诉automake不要这么较真:)

• config.guess config.sub：由automake产生，两个用于目标平台检测的脚本

• depcomp install-sh：由automake产生，用于完成编译和安装的脚本

• missing：由automake产生

• ltmain.sh：有libtoolize产生，该脚本用于在configure阶段配置生成可运行于目标平台的libtool脚本

• ylwrap：由automake产生，若是检测构建须要使用lex和yacc，那么会产生这个包装脚本

• autogen.sh：在早期，autoreconf并不存在，软件开发者每每须要本身编写脚本，按照顺序调用autoconf autoheader automake等工具程序。这个文件就是这样的脚本。起这么个名字多是习惯性的

总结

本文总概念上阐述了autotool系列工具是如何工做的。相好比今现成的IDE，GNU构建系统实际上是很是难用的，学习成本比较高。笔者认为最为效率的途径是学习开源的程序，从中慢慢体会，慢慢吸取。另外，推荐几个资料：

• 《GNU Autoconf Automake and Libtool》

• Autotools Tutorial

• GNU网站上关于autoconf automake 和 libtool的手册

笔者还有一些相关的笔记，后面再另外写一篇文章总结一下。