18、Autotools实战：完整项目配置流程、autoreconf命令、config.status与config.h、交叉编译配置

好，咱们今天来点真格的。前面讲了那么多Autotools的理论和文件结构，说实话，光看不动手，你很难真正理解这套工具链的脾气。我自己刚接触Autotools那会儿，也是对着configure.ac和Makefile.am发懵，总觉得这东西太绕了。直到亲手把一个项目从零搭起来，踩了几个坑之后，才慢慢摸到门道。

这一章，我们就拿一个实际的小项目来走一遍完整的流程。我会带着你从项目目录结构开始，一步步配置、生成构建系统，最后再聊聊交叉编译这个让人头疼的话题。

18.1 一个完整的实战项目：libhello

假设我们要写一个简单的库，叫libhello。它提供一个函数hello_print()，然后有一个测试程序来调用它。项目结构如下：

libhello/
├── src/
│   ├── hello.c
│   └── hello.h
├── tests/
│   └── test_hello.c
├── configure.ac
├── Makefile.am
├── src/Makefile.am
├── tests/Makefile.am
└── README

嗯，很典型的布局。源码放src/，测试放tests/，根目录放构建描述文件。

18.1.1 编写 configure.ac

这是整个Autotools的“心脏”。我习惯先写一个最小可用的版本，然后再慢慢加功能。来看这个例子：

AC_INIT([libhello], [1.0], [dev@example.com])
AM_INIT_AUTOMAKE([foreign])
AC_PROG_CC
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([Makefile
                 src/Makefile
                 tests/Makefile])
AC_OUTPUT

这里我用了foreign模式，意思是告诉Automake：“别那么严格，我不需要NEWS、AUTHORS这些文件。” 个人觉得，小项目用foreign省事很多。

18.1.2 编写 Makefile.am

根目录的Makefile.am很简单，就是告诉Automake要处理哪些子目录：

SUBDIRS = src tests

src/Makefile.am负责构建库：

lib_LTLIBRARIES = libhello.la
libhello_la_SOURCES = hello.c hello.h
include_HEADERS = hello.h

这里用了lib_LTLIBRARIES，表示我们要生成一个libtool库（.la文件）。如果你只需要静态库，也可以用lib_LIBRARIES，但libtool更灵活，支持动态和静态的切换。

tests/Makefile.am负责编译测试程序：

check_PROGRAMS = test_hello
test_hello_SOURCES = test_hello.c
test_hello_LDADD = ../src/libhello.la

注意check_PROGRAMS这个变量——它表示这些程序只在make check时构建，不会安装到系统里。这是Autotools的一个好习惯：测试代码和发布代码分开。

18.2 autoreconf：一键生成构建系统

文件都写好了，接下来就是见证奇迹的时刻。运行：

autoreconf -i

这个命令会依次调用autoconf、automake、aclocal等工具，生成configure脚本、Makefile.in模板、config.h.in等文件。-i选项表示“复制缺失的辅助文件”，比如install-sh、depcomp这些。

运行完之后，你会看到项目目录里多了很多文件。别慌，这些都是自动生成的。你真正需要维护的，只有configure.ac和各个Makefile.am。

18.3 config.status 与 config.h：配置的“快照”

当你执行./configure时，它实际上做了两件重要的事：

1. 生成config.status脚本
2. 根据config.h.in生成config.h

config.status是一个可重用的脚本，它记录了configure时的所有选项和检测结果。如果你只是改了Makefile.in或config.h.in，不需要重新跑configure，直接运行：

./config.status

它就会重新生成所有Makefile和config.h。这比重新跑configure快得多。

至于config.h，它是C/C++项目里最常用的配置头文件。比如你在configure.ac里写了：

AC_CHECK_HEADER([stdlib.h], [HAVE_STDLIB_H=1])

那么config.h里就会生成：

#define HAVE_STDLIB_H 1

你的源码里就可以用条件编译：

#ifdef HAVE_STDLIB_H
#include <stdlib.h>
#endif

18.4 交叉编译配置

交叉编译，说白了就是“在PC上编译出能在ARM板子上跑的程序”。Autotools对交叉编译的支持其实很成熟，但配置起来有几个关键点需要注意。

18.4.1 指定交叉编译工具链

假设你有一个ARM的交叉编译器叫arm-linux-gnueabihf-gcc，那么配置命令是：

./configure --host=arm-linux-gnueabihf CC=arm-linux-gnueabihf-gcc

--host参数告诉Autotools：“目标平台是ARM”。CC变量指定了编译器路径。Autotools会自动检测这个编译器是否可用，并调整一些检测逻辑。

18.4.2 处理依赖库的交叉编译

这是最头疼的部分。如果你的项目依赖了libpthread或libz，这些库也需要是交叉编译版本。我一般用两种方式解决：

• 使用交叉编译工具链自带的sysroot：很多工具链（比如Linaro的）都带了一个完整的根文件系统，里面包含了交叉编译好的库。你只需要指定--with-sysroot即可。
• 手动指定库路径：用LDFLAGS="-L/path/to/arm/libs"和CPPFLAGS="-I/path/to/arm/include"。

我曾经在一个项目里，因为忘了指定LDFLAGS，结果链接器抓到了宿主机的libz.so，编译出来的程序在ARM板子上直接段错误。嗯，从那以后我再也不敢马虎了。

18.4.3 验证交叉编译是否成功

配置完成后，可以检查config.log文件。里面会记录编译器检测的详细信息。你也可以直接看config.h里生成的宏，比如：

#define HOST_CPU "arm"

如果这个宏是arm而不是x86_64，说明交叉编译配置成功了。

18.5 本章知识体系

下面这张图总结了Autotools实战的核心流程和关键文件之间的关系：

从这张图可以看得很清楚：你只需要维护configure.ac和Makefile.am，剩下的工作全部交给Autotools自动完成。这就是它最大的价值——把构建系统的复杂性封装起来，让你专注于项目本身。

好了，这一章的内容就到这里。记住，Autotools虽然看起来繁琐，但一旦你掌握了这个流程，它就会成为你跨平台构建的得力助手。下次遇到需要交叉编译的项目，你就能从容应对了。

---