企业官网建设流程全解析

你上一次在终端里敲./configure && make && make install是什么时候？我用Linux这些年，见过不少朋友把./configure当“魔法按钮”：点了之后跑一会儿，Makefile自己就出来了，再make就能编译出二进制。直到有次我接手一个老旧C库的维护，被一坨configure.in里的m4宏折磨到凌晨，才真正开始研究背后这套东西。它的正式名字叫GNU Autotools，是整个GNU构建系统的基石，通常包括autoconf、automake、libtool，再加一个常被忽略的pkg-config。这篇博文想把这件事彻底讲透：它到底解决了什么问题、核心组件各自忙什么、一次完整的构建流程怎么走、路上有哪些坑，以及它对CMake、Meson这些后辈构建系统留下的遗产。适合刚接触Linux源码编译的入门朋友，也适合正在维护老项目、想搞明白“为什么这破项目还在用autotools”的开发者。

1. 为什么需要一套“构建系统”：从手写Makefile说起

1.1 手工维护Makefile的“石器时代”有多痛

很多年轻开发者第一次接触make时，会觉得Makefile就是“教编译器干活”的配置文件：写死源文件列表、写死编译选项、写死链接库，剩下的交给gcc。项目小的时候，这一套完全够用，几十行的Makefile我当年也随手写过。可当项目攒到三五百个源文件，分布在不同子目录，还依赖好几个第三方库的时候，手写Makefile就开始变成一场灾难。

依赖列表会漏。你改了某个头文件，理论上所有包含它的源文件都应该重编，但手写依赖规则根本维护不过来；链接选项会乱，同一个库在不同发行版上可能叫libabc.so、也可能叫libabc.a，还有的藏在/usr/lib/x86_64-linux-gnu/这种奇葩路径下。更要命的是跨平台——Linux、FreeBSD、macOS甚至Solaris，各有各的编译器默认行为、头文件路径和库命名规则。写一份“在所有机器上都能跑”的Makefile，基本等于要求一份源码在一个完全没有构建差异的平行世界里运行。

所以Unix社区很早就形成了一个共识：与其分发一份写死的Makefile，不如分发一个自动探测脚本。用户先跑脚本，脚本探测当前机器支持什么、缺什么，然后根据探测结果生成一份“本地适配”的Makefile。这个“探测-生成”的思想，就是Autotools诞生的起点。它不只是GNU的发明，而是整个开源软件分发模式的必然需求——发行版可以不同、架构可以不同、库版本可以不同，但源码包必须能在尽可能多的环境下从零构建成功。

1.2 平台差异的噩梦：从一行#include说起

有人会问：“我写的是C语言标准库，跨平台有那么难吗？”真没想象中简单。POSIX标准对着接口做了规定，但各家的实现程度参差不齐：某些老Unix系统缺strlcpy，某些BSD不支持某个GNU扩展函数，嵌入式环境的musl或uClibc可能砍掉了部分特性。代码想在不同系统上都编译过，几乎不可避免要写一堆条件编译：

#ifdef HAVE_STRLCPY strlcpy(dst, src, size); #else snprintf(dst, size, "%s", src); #endif

问题来了：HAVE_STRLCPY这个宏从哪里来？总不能靠程序员在每台机器上手动改头文件。Autotools的思路是：写一份探测脚本模板，自动编译一小段测试代码，看这个函数到底存不存在，然后把结果写进一个统一的头文件config.h。源码里只需要#include "config.h"，剩下的事交给预处理器判断。这个设计是第一代Autotools最具想象力的地方——把环境探测这个脏活，从程序员身上剥离出来，交给构建系统去自动完成。

这也解释了为什么今天你会看到大量开源包的源码目录里躺着一个config.h.in或config.h。前者是模板，后者是configure运行时生成的“环境体检报告”。你编译任何一个GNU风格的项目，第一步./configure实际上都在做一次全身体检：编译器有没有、标准头文件齐不齐、函数是否可用、库在哪个路径、字节序是大端还是小端，全都在这阶段查清楚。

1.3 Autotools家族全家福

整个Autotools体系，最核心的成员是这几个：

• autoconf：输入configure.ac，产出configure脚本。职责是把“平台特性探测清单”翻译成一段巨大的shell脚本，这段脚本可以在没有autoconf、没有m4、没有automake的干净系统上独立运行。
• automake：输入Makefile.am，产出Makefile.in。职责是把“有哪些程序要编译、由哪些源文件组成、需要哪些额外编译参数”这种高级描述，展开成完整的Makefile模板。
• libtool：负责共享库和静态库在不同平台上的编译与链接差异。Linux下是libxxx.so，macOS下是libxxx.dylib，Windows下是DLL，libtool把这套差异全部抹平。
• pkg-config：严格说不算Autotools本体，但它是Autotools生态里查依赖、取编译参数的标准工具。通过.pc文件暴露CFLAGS和LIBS，方便自动化构建系统调用。

一套常见的流水线是这样串起来的：先写configure.ac和Makefile.am，跑autoreconf -i自动生成configure和一系列模板文件，用户拿到源码包后依次执行./configure、make、make install。这条流水线太成功了，以至于成了开源世界的“标准安装仪式”。今天我们上GitHub拉代码后不自觉就敲./configure && make的肌肉记忆，十有八九都是拜Autotools所赐。

2. 核心组件逐个拆解：autoconf、automake与libtool

2.1 autoconf：自动探测系统的“侦察兵”

autoconf的核心机制很有意思：它基于m4宏语言，你在configure.ac里写的每一行“宏命令”，最终都会被展开成一段shell脚本。正确的打开方式是写“描述性”的宏，而不是手写shell逻辑。一个极简的configure.ac长这样：

AC_INIT([hello], [1.0], [bug@example.com]) AC_CONFIG_SRCDIR([hello.c]) AC_CONFIG_HEADERS([config.h]) AM_INIT_AUTOMAKE([foreign]) AC_PROG_CC AC_CHECK_HEADERS([stdlib.h string.h unistd.h]) AC_CONFIG_FILES([Makefile]) AC_OUTPUT

逐行拆开看：

• AC_INIT声明项目名、版本号和bug报告邮箱，这是所有宏的基础。
• AC_CONFIG_SRCDIR指定一个项目里必须存在的源文件。如果用户在错误的目录下运行configure，脚本会立刻提示“source directory not found”，避免在错误环境里跑一堆无用探测。
• AC_CONFIG_HEADERS启用config.h生成机制，后续所有探测结果的宏都会汇总到这个文件里。
• AM_INIT_AUTOMAKE把automake引入流程，参数foreign表示不强求项目里必须有AUTHORS、NEWS等GNU标准文档，适合个人小项目。
• AC_PROG_CC探测C编译器并设置CC和CFLAGS变量。
• AC_CHECK_HEADERS逐个探测头文件是否存在，存在则定义HAVE_XXX_H。
• AC_CONFIG_FILES声明需要由configure填充的模板文件列表，Makefile对应的模板是Makefile.in。
• AC_OUTPUT是终结指令，真正触发“填充模板、生成文件”的动作。

跑一次autoconf命令，输出的是一个几千甚至上万行的shell脚本。我第一次打开生成的configure时被吓到了——明明只写了十行宏，怎么就生成了这么大一坨？但这就是Autotools的聪明之处：分发源码时只分发生成好的configure，接收方不需要安装autoconf、m4或automake，只要有shell和基础工具链就能开始构建。这种“交付时降级为纯shell脚本”的思想，让Autotools在没有前置构建依赖的情况下自举成功，也是它能统治开源分发领域这么多年的底气之一。

2.2 automake：让Makefile.am里的声明变成完整Makefile

automake解决的问题是：手写完整Makefile太痛苦，我用一种更简洁的声明式语法来描述编译目标，剩下的交给工具生成。它的输入是Makefile.am，输出是Makefile.in，也就是configure要填充的模板。

一个hello项目的Makefile.am可以短到只有几行：

bin_PROGRAMS = hello hello_SOURCES = main.c utils.c AM_CPPFLAGS = -I$(top_srcdir)/include

• bin_PROGRAMS声明要生成一个安装到bindir的程序，名字叫hello。
• hello_SOURCES列出构成hello的源文件，automake会自动处理头文件依赖。
• AM_CPPFLAGS是全局预处理器参数，会应用到所有目标的编译命令上。

automake帮你自动生成的东西其实相当多：依赖跟踪文件、make clean和make distclean规则、make install时的目录创建、make uninstall的逆操作，以及最实用的make dist——它能根据SOURCES列表自动打包一个干净的源码tar包。日常CI里，很多人用DESTDIR配合make install把产物暂存到临时目录，方便打包成deb或rpm，这个参数也是automake内建支持的。

如果要做条件编译，比如“调试模式下才加上-DDEBUG”，Makefile.am里可以这样写：

if DEBUG AM_CFLAGS += -DDEBUG endif

对应的configure.ac里要用AC_ARG_ENABLE和AM_CONDITIONAL配合，后面实操章节我会带具体写法。这里先记住一个关键点：改构建逻辑务必改.am和.ac文件，再跑autoreconf重新生成，而不是直接改生成的Makefile。这是初学Autotools最容易踩的坑。

2.3 libtool：跨平台共享库的“翻译官”

共享库在不同系统上的命名和参数差异，是另一个让维护者头大的问题。Linux上编共享库用-shared -fPIC，产物是libfoo.so；macOS上要-dynamiclib，产物是libfoo.dylib；Windows上用MinGW还得处理导入库。libtool的存在就是把这些差异封装起来，写一次Makefile.am，在哪个平台都能编出正确的共享库。

典型的库目标是这样声明的：

lib_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = foo.c bar.c libfoo_la_LDFLAGS = -version-info 1:0:0

lt后缀暗示这是libtool对象。.la文件本质上是个文本元信息文件，记录了共享库的名字、依赖库列表、安装路径等，真正编译出来的.so会被放进隐藏的.libs/目录。很多新手在make之后找不到libfoo.so，其实是因为它藏在.libs/下面。

实际调试中，.la文件和.libs/目录也很有用。比如遇到链接时有undefined reference，先别急着怀疑代码，看看.libs/libfoo.so是不是真的生成了、符号是不是被strip掉了；再通过nm -D .libs/libfoo.so | grep 你要找的符号确认符号导出。现代发行版默认的链接选项可能带-Wl,--as-needed，导致某些依赖库在链接时被丢弃，这种问题在交叉编译和嵌入式场景尤其常见。临时用export LDFLAGS="-Wl,--no-as-needed"再重新configure，往往能快速定位是不是这种优化闯的祸。

2.4 依赖管理：pkg-config与AC_CHECK_LIB

C语言项目怎么声明“我依赖glib-2.0版本不低于2.40”？Autotools提供了两条路径。一条是传统做法AC_CHECK_LIB，直接在系统库里翻：

AC_CHECK_LIB([m], [pow], [], [AC_MSG_ERROR([libm not found])])

这种方法的局限很明显：只能检查“库文件存在与否”，无法精确核对版本号，也无法自动导出头文件路径。更现代的做法是通过pkg-config：

PKG_CHECK_MODULES([GLIB], [glib-2.0 >= 2.40])

这段宏会调用pkg-config查询glib-2.0.pc文件，成功后会导出GLIB_CFLAGS和GLIB_LIBS两个变量，你只要把它们加进Makefile.am的对应位置即可。这里的核心依赖是.pc文件——Debian系发行版通常把它放在/usr/lib/pkgconfig/或/usr/share/pkgconfig/，安装开发包时务必安装-dev后缀的软件包，比如apt install libglib2.0-dev。

这里说一个真实建议：如果你在Debian系发行版上开发，尤其是刚发布的debian gnu/linux 13 (trixie)这种新版本，务必先把apt源切到国内镜像，比如清华源，否则拉取依赖包的速度会让人崩溃。装完开发包之后，pkg-config --modversion glib-2.0可以快速验证版本号是否符合要求。另外/usr/local/lib/pkgconfig默认不在pkg-config的搜索路径里，自己编译安装到/usr/local的库，经常需要手动export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH，这是很多“明明装了库却找不到”问题的根源。

3. 一次完整的Autotools实战：从configure到make install

3.1 手工搭建一个最小工程树

理论知识说再多，不如亲手跑一遍。我建议你从零搭一个带子目录的小项目，体会整套流程。目录结构如下：

hello-autotools/ ├── configure.ac ├── Makefile.am └── src/ ├── Makefile.am ├── hello.c └── main.c

hello.c提供一个函数，main.c调用它：

/* src/hello.c */ #include <stdio.h> void hello_print(const char *name) { printf("Hello, %s!\n", name); }

/* src/main.c */ #include "hello.h" int main(void) { hello_print("Autotools"); return 0; }

根目录的configure.ac参考前面那版，Makefile.am用SUBDIRS声明子目录：

SUBDIRS = src

src/Makefile.am声明可执行文件：

bin_PROGRAMS = hello hello_SOURCES = hello.c main.c

然后打开终端，用任意喜欢的编辑器写这些文件。我用GNU nano比较多，nano configure.ac进去直接写，写完Ctrl+O保存、Ctrl+X退出，不需要会vim才能碰构建文件。

接下来是见证奇迹的时刻：

autoreconf -i

-i表示自动复制缺失的辅助文件，比如install-sh、missing、depcomp。这一步会一口气运行autoconf、automake、libtoolize、aclocal，生成configure、Makefile.in、aclocal.m4等一系列文件。之后再：

./configure make sudo make install

configure阶段会输出一堆checking消息，看到结尾出现config.status: creating Makefile就说明模板填充成功。make之后，src/下会出现编译产物，sudo make install会把hello安装到/usr/local/bin。此时在任意目录敲hello Autotools，如果打印出Hello, Autotools!，说明这套最小工程已经完整跑通。

3.2 configure参数与构建定制：--prefix、--enable、--with

Autotools的configure脚本不只“跑一下”这么简单，它还提供了一套统一的参数约定，让使用者可以在编译阶段做决策。

最常用的是--prefix，指定安装根目录：

./configure --prefix=/usr ./configure --prefix=$HOME/opt/hello

第二个命令会把程序装到用户目录，不需要sudo。更细分的还有--libdir和--includedir，分别控制库和头文件的安装位置，在做发行版打包或迁移软件时非常有用。

除了路径，还常用--enable-xxx和--with-xxx控制功能开关。前者通常用于编译特性，后者通常用于外部依赖。实现方式是在configure.ac里加AC_ARG_ENABLE：

AC_ARG_ENABLE([debug], [AS_HELP_STRING([--enable-debug], [enable debug output])], [enable_debug=yes], [enable_debug=no]) AM_CONDITIONAL([DEBUG], [test "$enable_debug" = yes])

然后Makefile.am里用条件判断：

if DEBUG AM_CFLAGS += -DDEBUG endif

AS_HELP_STRING的作用是让自定义参数自动出现在./configure --help的帮助文本里，格式整齐。我第一次写这个宏时没加它，结果--help里看不到自己的参数，还以为写错了位置，后来才明白是帮助字符串缺失导致的功能性瑕疵。跑./configure --enable-debug，config.h里就会多出DEBUG宏，Makefile的编译命令也会追加-DDEBUG，代码里就能用#ifdef DEBUG做分支。这类约定让“用户配置项目功能”变成了一件标准化的事。

3.3 交叉编译：嵌入式Linux系统构建的实战场景

Autotools里最容易被忽视但含金量极高的能力，是交叉编译。以现在很常见的嵌入式场景为例：你要给一块启明星Zynq开发板（ARM架构）构建能在板子上跑的程序，主机是x86的Linux工作站。这种情况下，本机的gcc编译出的程序根本没法定在ARM板子上运行，必须使用对应的交叉工具链。

configure脚本里跟平台相关的参数有三个：

• --build：当前构建主机所在平台。
• --host：目标程序要运行的平台。
• --target：只有在构建交叉编译器本身时才需要，普通应用开发不用管。

交叉编译时最关键的是指定--host，并让CC指向交叉编译器：

./configure --host=arm-linux-gnueabihf \ CC=arm-linux-gnueabihf-gcc \ CPPFLAGS=-I/path/to/sysroot/usr/include \ LDFLAGS=-L/path/to/sysroot/usr/lib

忘记写--host是嵌入式新手最常见的错误。如果不写，configure会尝试用主机gcc编译一个测试程序并在主机上运行，紧接着报出“cannot run C compiled programs”或“C compiler cannot create executables”。实际在Zynq这类板子的开发里，芯片厂商提供的工具链往往自带一套sysroot，里面有目标板对应的头文件和库，你必须把CPPFLAGS、LDFLAGS都指到sysroot里，而不是主机默认路径。依赖库的.pc文件也一样，需要配合PKG_CONFIG_SYSROOT_DIR或手动指定搜索路径，否则pkg-config查到的还是主机库，链接阶段会得到一堆风格迥异的“relocation truncated to fit”错误。

Autotools的“探测-生成”机制在交叉编译中依然有效，区别在于探测的是目标环境而不是当前环境。理解了这一点，你在嵌入式Linux系统构建时就会少走很多弯路。

3.4 构建提速与发布前的自检

日常迭代时，有两条命令值得记牢。第一条是并行编译：

make -j$(nproc)

nproc会返回CPU核心数，-j让make同时跑多个编译任务，大项目提速非常明显。配合ccache还能进一步缓存编译结果，反复clean后重建时特别有效。

第二条是发布前自检：

make dist make distcheck

make dist会生成一个hello-autotools-1.0.tar.gz源码包；make distcheck则会模拟一位全新用户的行为：解压源码包、重新执行configure、make、make install、make uninstall，且全程在一个临时目录里进行。如果distcheck能通过，说明你的源码包对用户来说足够友好——该带的文件都带上了，构建依赖也声明清楚了。我实战中见过不少次make dist能过但make distcheck挂掉的情况，一查往往是某个新增的测试数据文件忘了写进EXTRA_DIST，或者某些辅助脚本被临时生成到了源码目录而没有被打包。这条命令的“找茬”能力，能帮你在用户之前发现一堆发布事故。

4. 常见问题与排查技巧实录

4.1 configure失败：no acceptable C compiler found

这个报错算是最入门级的，原因通常是系统里连gcc都没装。Debian系发行版执行apt install build-essential就能解决，它会带上gcc、make、libc-dev等一套基础工具链。

但我也遇到过一种更隐蔽的情况：主机上已经装了clang，cc符号也指向了clang，但某个老项目用AC_PROG_CC探测时，对clang的C99标准兼容性判断有疑虑，于是报同样错误。解决办法是显式指定编译器：

CC=gcc ./configure

如果这样还不行，去看config.log。这个文件记录了configure所有探测命令和输出，每次configure失败后它都会安静地躺在目录里。翻到日志末尾的failed command，通常能看到真正报错的编译命令——比如缺了as或ld，说明binutils没装；比如头文件缺失，说明缺了对应的-dev包。configure报错别只看最后三行，要顺着config.log找到“测试命令本身报了什么错”，这才是解决问题最快的路径。

4.2 链接时undefined reference：区分编译期和运行期

链接期报undefined reference to 'xxx'，最经典的原因是库的顺序错了。GNU ld对静态库的扫描有顺序依赖：被依赖的库要放在依赖者的后面。如果你手写的LIBS顺序不对，符号就找不到。在Autotools项目里，补充库依赖时注意看Makefile.am里的LDADD或xxx_LDADD，把库名按依赖关系从“被依赖方”到“依赖方”排列。

运行期报undefined symbol则是另一码事。可能原因是链接时-Wl,--as-needed把某些共享库丢弃了，程序又能启动，但运行到某个函数时才发现符号没链接进来。排查套路是先看依赖：

ldd ./hello nm -D /path/to/libxxx.so | grep symbol

如果libxxx.so确实存在却还是找不到符号，临时加LDFLAGS="-Wl,--no-as-needed"重新configure再验证。嵌入式场景里还有一种更气人的：交叉工具链的sysroot里那个so是为ARM板子编译的，但pkg-config通过主机路径给它传入设置导致桌面上也能检出，链接时混用了两个环境的库，结果报错风格非常诡异。遇到这类问题，先确认pkg-config --libs返回的路径全都在sysroot下，不要在主机默认路径里混搭。

4.3 宏版本错误与autogen.sh的正确打开方式

configure.ac里用了较新的宏，但系统里的autoconf太老，会报“macro AM_XXX not found”或“require autoconf 2.69”。另外，如果工程里有LT_INIT（libtool的初始化宏）但系统没装libtool，或者autoreconf没有正确运行，会出现“libtool library used but libtool is not defined”。这类问题的通用处理方案是手动跑一遍全套生成命令：

libtoolize --force aclocal -I m4 autoconf --force automake --add-missing --copy

顺序有讲究：先libtoolize处理共享库宏，再aclocal收集项目里的m4宏，然后autoconf生成configure，最后automake补全辅助文件。这些命令写进一个autogen.sh脚本里，后续每次修改构建文件后执行它，就能避免“到底先跑哪个”的记忆负担。

还要记住一个原则：不要直接编辑configure脚本本身。它在文件顶部往往有一句“It is a distribution generated file, do not edit”，意思很明显——你改了也会被重新生成覆盖。正确的做法是改configure.ac和Makefile.am，然后重新跑autoreconf。这个坑我当年踩过好多次，每次都是改了一堆configure里的shell逻辑，下次autoreconf之后全部白干。

4.4 运维向避坑速查表

再补充一条Debian系发行版的经验：在debian gnu/linux 13 (trixie)这类新版本上开发时，换完国内镜像源后一定要先执行apt update，否则apt缓存里还是旧索引，容易装到不匹配的版本，进而触发.pc版本探测失败。这类问题跟Autotools本身无关，但它是所有“configure: error: Package requirements not met”背后最常见的基础环境因素。

5. Autotools的“遗产”：它留给后辈构建系统的财富

5.1 被吐槽了几十年，为什么还没退休

Autotools被吐槽的点确实不少：生成的configure脚本动辄上万行、报错信息晦涩、m4宏可读性差、调试体验糟糕。这些都是真实存在的痛点，我双手赞成。但它也有一项至今难以替代的能力：分发物只依赖sh和基础工具链，而不依赖autoconf本身。这种“生成物自包含”的设计，让源码包可以在非常老旧或非常小众的系统上构建。

另一个核心遗产是生态惯性。GNU风格项目、绝大多数Unix工具、大量科学计算库，至今仍然使用Autotools维护。它们没有迁移到CMake，不是因为开发者守旧，而是因为构建系统迁移的成本极高：要重写所有平台的依赖探测、重做一个稳定的install规则、保证交叉编译行为不变。在开源项目维护者普遍时间不够用的前提下，“跑得好好的就别动它”成了最理性的选择。

5.2 CMake、Meson与Ninja的进击

后来者里，CMake是影响力最大的。它把语法改成了更接近编程语言的风格，内置find_package模块化查找依赖，原生支持out-of-source构建，还覆盖了Windows、macOS、Linux全平台。Meson则更进一步，用Python-like语法提升可读性，配合Ninja构建后端把生成速度拉到极快。

CMake成了现代C++领域的实际标准，Meson则在追求“开箱即用且快速”的新项目里越来越流行。三者之间并不是简单的新旧替代关系——在Linux生态里，pkg-config至今仍是底层依赖发现的通用语言，CMake和Meson都在调用它。Autotools虽然在“用户交互层”上退居二线，但它定义的.pc文件、--prefix约定、out-of-source构建思想，已经渗透进几乎所有后辈工具的基因里。

5.3 从“探测-生成”到现代构建思想

我个人的理解是，Autotools最大的遗产不是某个命令，而是一套“先探测环境、再生成配置、后执行编译”的流程哲学。现代构建系统的高层设计思路，其实都在重复这个模式：CMake的configure阶段会探测编译器特性、检查依赖库；Meson用machine file描述交叉编译目标；甚至我在一篇讲数据系统构建的文章里看到，有斯坦福的研究者用专门的小工具构建数据流水线时，强调的核心思路依然是“把环境感知、依赖声明与执行过程分开”。这说明“探测-生成”的价值已经远远超出C语言编译的范围，它是一种普适的系统工程方法论。

更巧的是，这种稳定性也让很多GNU生态的顶层软件受益。GNU Octave这类科学计算工具，从早期一路维护到今天，依然保持着源码分发、构建、安装的全流程稳定；而这些都要依赖底层构建体系在数十年里保持向后兼容。Autotools未必漂亮，但它用几十年时间验证了一件事：一套稳定的构建系统，本身就是开源软件最重要的基础设施之一。

5.4 给新手的上手路线建议

如果你刚接触Autotools，我的建议是不要上来就啃宏文档。按照这个顺序来，进步会快很多：

1. 先学会“读”：找一个简单的开源项目，打开configure.ac，对照文档看懂每一行宏的含义。
2. 再学会“跑”：熟悉autoreconf -i、./configure、make三步走的完整流程，观察中间生成了哪些文件。
3. 然后尝试“抄”：复制一个最小工程，改名字、改源文件，直到能独立跑通构建。
4. 接着加“条件”：给项目加--enable-debug、加pkg-config依赖查询，体会AC_ARG_ENABLE和PKG_CHECK_MODULES怎么联动。
5. 最后挑战“交叉”：给Zynq这类嵌入式板子尝试交叉编译一次，理解--host、sysroot、pkg-config三者的关系。

这套路线走完，你会比那些只会跑cmake .. && make的开发者多一层底层的理解力。以后再遇到老项目构建失败，或嵌入式Linux系统构建时的怪异报错，你至少知道该从哪里下手查。

最后说一点我实际维护开源库时的体会。我手里有一个老C库，到现在还在用Autotools。不是因为它完美，而是因为它稳：不会因为升级某个工具链版本就崩，用户clone下来跑一遍就完事，不会因为缺CMake而多一句抱怨。这套体系也许看起来不够“现代”，但它那种“生成好的脚本在任何系统上都能自举”的理念，放到今天依然有很强的参考价值。如果你第一次接触Autotools，别急着否定它，花一个下午从hello world开始跑一遍，你会明白那个被无数人吐槽的./configure，到底替你挡了多少跨平台的麻烦。以后做嵌入式板子交叉编译、接手老项目、甚至设计一套自己的自动化构建流程，这套知识都会变成你最值钱的经验之一。