企业官网建设流程全解析

1. 为什么多目录项目让autotools新手直接卡在configure脚本里

“autotools能自动生成Makefile”——这句话听上去很美，但当你第一次把项目从单个src/目录拆成src/,lib/,include/,tests/,doc/五个子目录时，就会发现：./configure跑通了，make却报错说找不到libfoo.a；或者make install把头文件装到了/usr/local/include/src/这种诡异路径；更常见的是，make clean只清掉了src/里的.o文件，lib/和tests/目录下的编译产物纹丝不动。

这不是你不会写Makefile，而是你没真正理解autotools的目录驱动哲学。它不靠人工写规则去遍历子目录，而是靠一套分层的、声明式的“构建拓扑描述”来组织整个项目结构。Makefile.am不是Makefile的简化版，它是构建意图的DSL；configure.ac也不是配置检查脚本，它是整个项目构建图谱的元数据注册中心。

我见过太多开发者，在单目录项目里用bin_PROGRAMS = hello加几行hello_SOURCES就跑通了，一到多目录就去网上搜“autotools subdirectory”，然后硬生生在Makefile.am里写$(MAKE) -C lib这种反模式操作。结果是：make -j4并行编译时出现依赖混乱；make distcheck打包失败；make uninstall根本删不干净。这些都不是bug，是autotools在用报错告诉你：“你没按它的世界观来建模”。

核心矛盾在于：Makefile是面向过程的指令流，autotools是面向结构的声明式建模工具。你要做的不是“让autotools生成一个能进子目录的Makefile”，而是“告诉autotools：我的项目由哪些逻辑模块组成，它们之间是什么依赖关系，每个模块的源码放在哪，输出目标放哪，安装路径又该映射到系统哪个位置”。

所以本篇不讲“怎么写”，先讲“怎么想”。下面这张表，是我带过的十几个跨平台C/C++项目总结出的、最常被忽略的多目录建模三原则：

这三条原则背后，是autotools对Unix哲学的极致贯彻：每个目录是一个职责单一的构建单元，每个Makefile.am是一份契约，约定“我提供什么、我需要什么、我安装到哪”。你写的不是代码，是在给整个构建系统画一张精确的工程地图。

提示：很多教程让你在configure.ac里写AC_CONFIG_FILES([Makefile lib/Makefile src/Makefile])，这是过时的写法。现代autotools（2.69+）只要AC_CONFIG_SUBDIRS和正确的SUBDIRS声明，automake会自动推导所有子目录的Makefile.in生成规则。手动列出反而容易漏掉tests/Makefile或doc/Makefile，导致make distcheck失败。

2. 从零搭建一个真实可用的多目录项目骨架

我们不拿“hello world”练手，直接构建一个有生产价值的结构：一个命令行工具imgproc，它调用底层图像处理库libimgcore，头文件放在include/，单元测试用check框架放在tests/，文档用doxygen生成放在doc/。整个项目目录树如下：

imgproc-project/ ├── configure.ac ├── Makefile.am # 顶层：声明子目录、全局编译标志 ├── README.md ├── include/ # 头文件安装目录 │ └── imgcore.h ├── lib/ # 静态/动态库源码 │ ├── Makefile.am # 定义libimgcore.la │ └── core.c ├── src/ # 主程序源码 │ ├── Makefile.am # 定义imgproc二进制 │ └── main.c ├── tests/ # 单元测试 │ ├── Makefile.am # 定义check测试套件 │ └── test_core.c └── doc/ # 文档生成 ├── Makefile.am # 定义doxygen目标 └── Doxyfile.in

2.1 顶层Makefile.am：构建系统的总控室

顶层Makefile.am不写任何编译规则，它只做三件事：声明子目录顺序、设置全局编译参数、定义打包行为。这是最容易被写错的地方——很多人在这里堆砌bin_PROGRAMS或lib_LTLIBRARIES，结果导致子目录的Makefile.am被忽略。

# imgproc-project/Makefile.am # SUBDIRS定义构建顺序：lib必须在src之前，因为src依赖lib SUBDIRS = include lib src tests doc # 全局CFLAGS：所有子目录都会继承，避免在每个Makefile.am里重复写 AM_CFLAGS = -Wall -Wextra -std=c99 # 全局预处理器标志：-I$(top_srcdir)/include让所有源码都能#include "imgcore.h" AM_CPPFLAGS = -I$(top_srcdir)/include # 打包时包含哪些文件：README.md和configure.ac是必须的，其他由子目录自行声明 EXTRA_DIST = README.md # 禁用递归make的警告（现代autotools已默认启用，此行可选） AUTOMAKE_OPTIONS = subdir-objects

关键点解析：

• SUBDIRS = include lib src tests doc的顺序不是随意的。include/排第一，是因为lib/和src/都需要它；lib/排第二，因为src/要链接它；tests/排第四，因为它要链接lib/和src/的测试桩。automake会严格按此顺序执行make all，确保依赖满足。
• $(top_srcdir)是autotools内置变量，指向源码根目录（即configure.ac所在位置）。它和$(srcdir)（当前Makefile.am所在目录）的区别，是新手最常混淆的点。$(top_srcdir)/include保证了无论你在lib/还是src/目录下编译，都能找到头文件。
• AUTOMAKE_OPTIONS = subdir-objects是强制要求。它让automake把每个子目录生成的.o文件放在各自目录下（如lib/core.o），而不是全堆在顶层。没有它，make clean会失效，make -j4可能因文件名冲突而崩溃。

2.2 include/Makefile.am：头文件的“不动产登记”

头文件目录看似简单，实则是多目录项目中最易出错的一环。错误做法是把imgcore.h直接放在lib/里，然后在src/main.c里写#include "../lib/imgcore.h"。这会导致两个问题：make install时头文件不会被安装；make distcheck打包时，lib/目录下的头文件不会被包含进发布包。

正确做法：include/目录本身就是一个独立的安装单元。

# imgproc-project/include/Makefile.am # 声明要安装的头文件列表 include_HEADERS = imgcore.h # 可选：如果头文件需要预处理（如版本号替换），用BUILT_SOURCES # BUILT_SOURCES = imgcore.h # imgcore.h: imgcore.h.in # $(AM_V_GEN) sed 's/@VERSION@/$(PACKAGE_VERSION)/g' $< > $@

这里include_HEADERS是autotools的魔法变量名，include_前缀对应$(includedir)安装路径（默认/usr/local/include）。automake看到这个变量，就会自动生成安装规则：make install时把imgcore.h拷贝到$(DESTDIR)$(includedir)/imgcore.h。

注意：include_HEADERS中的include_是固定前缀，不能改成mylib_HEADERS或public_HEADERS。autotools只认bin_,sbin_,lib_,include_,data_等标准前缀。这是它的契约，不是配置项。

2.3 lib/Makefile.am：构建可重用库的核心战场

lib/目录是整个项目的基石。这里要同时产出静态库（.a）、动态库（.so或.dll）和libtool封装的.la文件。libtool的存在，是为了屏蔽不同Unix系统上动态库命名（libfoo.so.1.0.0vslibfoo.dylib）和链接方式（-lfoovs-lfoo.1）的差异。

# imgproc-project/lib/Makefile.am # 定义要构建的库名称和源文件 lib_LTLIBRARIES = libimgcore.la # libimgcore.la的源文件 libimgcore_la_SOURCES = core.c # 关键：libtool链接标志，确保生成可移植的.la文件 libimgcore_la_LDFLAGS = -no-undefined -version-info 1:0:0 # 可选：如果库需要链接外部系统库（如math），在此声明 # libimgcore_la_LIBADD = -lm # 可选：为库添加pkg-config元数据（强烈推荐） pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = imgcore.pc imgcore_pc_in_files = imgcore.pc.in imgcore.pc: $(imgcore_pc_in_files) $(AM_V_GEN) sed -e 's/@PACKAGE_VERSION@/$(PACKAGE_VERSION)/g' \ -e 's/@prefix@/$(prefix)/g' \ -e 's/@exec_prefix@/$(exec_prefix)/g' \ -e 's/@libdir@/$(libdir)/g' \ -e 's/@includedir@/$(includedir)/g' \ $< > $@ EXTRA_DIST += imgcore.pc.in

逐行解释：

• lib_LTLIBRARIES = libimgcore.la：lib_前缀表示安装到$(libdir)（默认/usr/local/lib），LTLIBRARIES后缀表示使用libtool构建。automake会据此生成libimgcore.la、libimgcore.a、libimgcore.so三个文件。
• -no-undefined：这是libtool的生死开关。没有它，libtool在AIX或HP-UX上会拒绝构建动态库，因为这些系统要求所有符号在构建时就必须解析完毕。加上它，libtool会生成一个“存根库”，在运行时才解析符号，保证跨平台兼容性。
• -version-info 1:0:0：控制动态库的版本号。格式为current:revision:age。1:0:0表示主版本1，无修订，无兼容旧版本能力。生产环境应设为2:1:1（主版本2，修订1次，向后兼容1个主版本）。
• pkgconfig_DATA部分：生成imgcore.pc文件，供其他项目用pkg-config --cflags --libs imgcore获取编译和链接参数。imgcore.pc.in是模板文件，内容类似：

  prefix=@prefix@ exec_prefix=@exec_prefix@ libdir=@libdir@ includedir=@includedir@ Name: imgcore Description: Core image processing library Version: @PACKAGE_VERSION@ Libs: -L${libdir} -limgcore Cflags: -I${includedir}

2.4 src/Makefile.am：主程序的链接艺术

src/目录的任务是把libimgcore和main.c链接成最终的imgproc可执行文件。难点在于：如何让src/“看见”lib/生成的库？答案不是-L../lib -limgcore，而是用libtool的跨目录引用机制。

# imgproc-project/src/Makefile.am # 定义要构建的可执行文件 bin_PROGRAMS = imgproc # imgproc的源文件 imgproc_SOURCES = main.c # 关键：链接依赖！必须用../lib/libimgcore.la，而不是-limgcore imgproc_LDADD = ../lib/libimgcore.la # 可选：如果main.c需要额外的链接库（如pthread） # imgproc_LDADD += -lpthread # 可选：为可执行文件添加安装时的符号链接（如imgproc -> imgproc-1.0） # imgproc_PROGRAMS = imgproc # imgproc_LINK = $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@

核心原理：

• imgproc_LDADD = ../lib/libimgcore.la这行是灵魂。LDADD变量告诉automake：“构建imgproc时，除了main.o，还要链接../lib/libimgcore.la”。libtool会智能地：
  • 如果libimgcore.la是静态库，就直接归档libimgcore.a；
  • 如果是动态库，就生成-L../lib -limgcore链接参数；
  • 同时，libtool会把libimgcore.la中记录的-rpath（运行时库搜索路径）注入到imgproc的二进制中，确保./imgproc能直接运行，无需export LD_LIBRARY_PATH。
• 绝对不能写imgproc_LDFLAGS = -L../lib -limgcore。LDFLAGS是传给gcc的原始参数，libtool无法介入，会导致make install后/usr/local/bin/imgproc找不到/usr/local/lib/libimgcore.so。

2.5 tests/Makefile.am：让单元测试成为构建流水线一环

tests/目录常被当作“附加功能”，但生产级项目必须让它和主代码一样受CI管控。check框架是autotools原生支持的测试方案，其优势在于：make check会自动运行所有测试，make distcheck会先make check再打包，确保发布包的完整性。

# imgproc-project/tests/Makefile.am # 启用check框架 TESTS = test_core check_PROGRAMS = test_core # test_core的源文件 test_core_SOURCES = test_core.c # 链接libimgcore和check库 test_core_LDADD = ../lib/libimgcore.la -lcheck -lm # 关键：让test_core在运行时能找到libimgcore（尤其在VPATH构建中） test_core_LDFLAGS = -rpath ../lib # 可选：定义测试超时（秒） # TEST_TIMEOUT = 30 # 可选：如果测试需要数据文件，用TESTS_ENVIRONMENT传递环境变量 # TESTS_ENVIRONMENT = IMGPROC_TEST_DATA=$(srcdir)/test_data

关键点：

• TESTS = test_core和check_PROGRAMS = test_core必须成对出现。TESTS定义运行时执行的程序列表，check_PROGRAMS定义构建时要编译的程序列表。automake会为check_PROGRAMS生成编译规则，并确保make check时先make它们。
• -rpath ../lib是调试阶段的救命稻草。它告诉test_core：“运行时优先在../lib目录下找libimgcore.so”。这样你不用make install就能make check，极大提升开发效率。注意：-rpath只在make check时生效，make install后/usr/local/bin/test_core会使用-rpath /usr/local/lib。

3. configure.ac的精密手术：让autoconf读懂你的项目拓扑

configure.ac是autotools的“大脑”，它不直接生成Makefile，而是生成configure脚本，后者根据用户环境（操作系统、编译器、库存在性）动态生成最终的Makefile。多目录项目中，configure.ac的核心任务是：注册所有子目录的构建入口，并为跨目录依赖提供元数据。

# imgproc-project/configure.ac AC_INIT([imgproc], [1.0.0], [bugs@example.com]) AC_CONFIG_AUX_DIR([build-aux]) AC_CONFIG_MACRO_DIRS([m4]) # 核心：声明所有子目录的Makefile.in生成点 # 注意：顺序必须和顶层Makefile.am中的SUBDIRS一致！ AC_CONFIG_FILES([ Makefile include/Makefile lib/Makefile src/Makefile tests/Makefile doc/Makefile ]) # 标准初始化 AM_INIT_AUTOMAKE([-Wall -Werror foreign subdir-objects]) # 检查编译器和基础工具 AC_PROG_CC AC_PROG_LIBTOOL # 必须！没有它，lib_LTLIBRARIES无法工作 # 检查头文件和函数（示例：检查是否支持posix_memalign） AC_CHECK_HEADERS([stdlib.h unistd.h]) AC_CHECK_FUNCS([posix_memalign]) # 检查外部库依赖（示例：如果libimgcore需要OpenCV） # PKG_CHECK_MODULES([OPENCV], [opencv_core >= 4.5.0], [], [ # AC_MSG_ERROR([OpenCV 4.5.0 or later is required]) # ]) # 检查测试框架（用于tests/Makefile.am） AC_CHECK_PROG([CHECK_PROG], [pkg-config], [yes], [no]) if test "x$CHECK_PROG" = "xno"; then AC_MSG_ERROR([pkg-config is required to find check library]) fi PKG_CHECK_MODULES([CHECK], [check >= 0.15.0]) # 检查文档工具（用于doc/Makefile.am） AC_CHECK_PROG([DOXYGEN], [doxygen], [yes], [no]) if test "x$DOXYGEN" = "xno"; then AC_MSG_WARN([doxygen not found, documentation will not be built]) fi # 输出配置摘要 AC_CONFIG_HEADERS([config.h]) AC_OUTPUT # 最后一行：打印构建概览 echo " imgproc $PACKAGE_VERSION configuration complete. Build options: Compiler: $CC Install prefix: $prefix Library dir: $libdir Include dir: $includedir Optional features: Tests: ${CHECK_TRUE:+enabled} ${CHECK_FALSE:+disabled} Documentation: ${DOXYGEN:+enabled} ${DOXYGEN:+disabled} "

逐项深挖：

• AC_CONFIG_FILES([...])列表必须精确匹配SUBDIRS中的所有目录，且顺序一致。automake会扫描这个列表，为每个条目生成对应的Makefile.in。漏掉tests/Makefile，make check就永远是make: *** No rule to make target 'check'. Stop.。
• AM_INIT_AUTOMAKE([-Wall -Werror foreign subdir-objects])中的subdir-objects选项，与顶层Makefile.am中的AUTOMAKE_OPTIONS呼应，是启用子目录对象文件隔离的双保险。
• AC_PROG_LIBTOOL是lib_LTLIBRARIES的命脉。没有它，automake会报错required file './ltmain.sh' not found。libtool的ltmain.sh脚本会被autoreconf自动复制到build-aux/目录。
• PKG_CHECK_MODULES是现代autotools的标配。它用pkg-config查询系统库的编译和链接参数，并将结果存入CHECK_CFLAGS和CHECK_LIBS变量，供tests/Makefile.am中的test_core_CFLAGS和test_core_LDADD直接引用。比手写AC_CHECK_LIB更可靠、更简洁。
• AC_CONFIG_HEADERS([config.h])生成config.h头文件，其中包含#define HAVE_POSIX_MEMALIGN 1等宏。src/main.c可以安全地#ifdef HAVE_POSIX_MEMALIGN，实现条件编译。

提示：configure.ac中所有AC_CHECK_*宏的检测结果，都会被写入config.log。当./configure失败时，不要只看终端报错，务必打开config.log搜索configure: error:，那里有gcc的真实编译命令和错误输出，是定位问题的黄金线索。

4. 从configure到install：一次完整的多目录构建流水线实录

理论讲完，现在用真实命令行复现一次从零开始的构建过程。这不是教科书式的理想流程，而是我在某嵌入式图像处理项目中，连续三天调试make distcheck失败后，总结出的生产环境黄金步骤。每一步都附带“为什么必须这样”和“不这样会怎样”的血泪教训。

4.1 初始化：autoreconf不是万能钥匙，但它是唯一起点

很多新手以为./configure脚本天生就有，其实它是由autoreconf从configure.ac和Makefile.am生成的。autoreconf是autotools的“编译器”，它依次调用aclocal、autoconf、automake等工具。

# 进入项目根目录 cd imgproc-project # 第一步：清理所有自动生成文件（非常重要！） git clean -fdx # 第二步：运行autoreconf（-f强制覆盖，-i安装缺失的辅助文件） autoreconf -fiv # 第三步：检查生成物 ls -F # 应该看到：configure* aclocal.m4 autom4te.cache/ config.h.in Makefile.in ... # 如果没有configure，说明autoreconf失败，立刻看终端最后一行错误

关键细节：

• git clean -fdx是防止“幽灵文件”作祟的铁律。autoreconf会读取aclocal.m4、configure等旧文件，如果它们残留着旧版本的宏定义，会导致新configure.ac中的PKG_CHECK_MODULES被忽略。我曾因此浪费8小时，最后发现是aclocal.m4里有一行m4_ifdef([AC_PROG_LIBTOOL], [...])没被更新。
• autoreconf -fiv中的-v（verbose）是调试神器。它会打印出每一步调用的命令：aclocal: installing 'm4/libtool.m4' from '/usr/share/aclocal/libtool.m4'。如果看到aclocal: warning: couldn't open directory 'm4': No such file or directory，说明你忘了创建m4/目录，PKG_CHECK_MODULES宏就无法被找到。

4.2 配置：./configure的隐藏参数与陷阱

./configure不是黑盒，它的每一个参数都在塑造最终的构建行为。生产环境必须显式指定关键路径，否则make install会污染系统。

# 创建独立的构建目录（强烈推荐！VPATH构建） mkdir build && cd build # 执行configure，显式指定所有关键路径 ../configure \ --prefix=$HOME/local \ # 安装到用户目录，避免sudo --enable-static \ # 强制构建静态库（便于嵌入式部署） --disable-shared \ # 禁用动态库（减少依赖，提高确定性） --with-pic \ # 生成位置无关代码（PIC），为动态库做准备 --enable-debug \ # 启用调试符号（-g），禁用优化（-O0） CFLAGS="-O2 -march=native" \ # 覆盖默认CFLAGS，启用CPU本地优化 LDFLAGS="-Wl,-rpath,$HOME/local/lib" # 硬编码运行时库路径 # 检查configure输出的关键信息 grep -E "(prefix|libdir|includedir|Build.*static)" config.log # 应该看到：prefix='/home/you/local', libdir='${exec_prefix}/lib', Build static libraries: yes

致命陷阱：

• 绝对不要在源码目录下运行./configure。这叫in-source build，会导致Makefile、.o文件和源码混在一起，git status一片红，make clean无法清理干净。VPATH构建（源码和构建分离）是autotools的官方推荐。
• --enable-static --disable-shared组合，是嵌入式和容器化部署的黄金搭档。它确保make install只生成libimgcore.a，没有.so文件，彻底规避LD_LIBRARY_PATH和rpath的烦恼。--with-pic则为未来可能的动态库需求留后路。
• LDFLAGS="-Wl,-rpath,$HOME/local/lib"是make install后./imgproc能直接运行的保障。-Wl,表示把后面的参数透传给链接器ld，-rpath则硬编码库搜索路径。没有它，./imgproc会报error while loading shared libraries: libimgcore.so: cannot open shared object file。

4.3 构建：make的并行与静默艺术

make是autotools的执行引擎，但它的默认行为对多目录项目并不友好。

# 1. 清理上次构建（重要！） make clean # 2. 并行编译：-jN，N=CPU核心数+1（充分利用IO等待） make -j5 V=0 # V=0关闭详细输出，V=1显示完整gcc命令 # 3. 验证构建产物 ls -lh src/imgproc lib/libimgcore.a tests/test_core # src/imgproc: 可执行文件，大小约200KB # lib/libimgcore.a: 静态库，大小约500KB # tests/test_core: 测试程序，大小约150KB # 4. 运行单元测试（验证lib和src的集成） make check # 应该看到：PASS: test_core

深度解析：

• make clean必须在每次configure后执行。因为configure会重新生成Makefile，旧的Makefile可能还保留着lib/目录下不存在的.o文件规则，导致make clean漏删。
• make -j5 V=0中的-j5是经验公式：nproc + 1。V=0关闭详细输出，让make只打印“正在构建什么”，不打印冗长的gcc -I... -c ...命令。调试时用V=1，日常构建用V=0，这是效率与可读性的平衡。
• make check是tests/Makefile.am中TESTS变量的触发器。它会自动执行./test_core，并捕获返回值。如果test_core返回非0，make check就失败，CI流水线立即中断。

4.4 安装与验证：DESTDIR是沙箱安装的灵魂

make install不是终点，而是分发的起点。生产环境绝不能直接make install到/usr/local，必须用DESTDIR进行沙箱安装。

# 1. 创建沙箱安装目录 mkdir -p $HOME/staging # 2. 沙箱安装（DESTDIR是只读前缀，不影响prefix） make DESTDIR=$HOME/staging install # 3. 检查沙箱内容（这才是你真正要打包的东西） tree $HOME/staging # 应该看到： # └── home # └── you # └── staging # └── local # ├── bin/ # │ └── imgproc* # ├── include/ # │ └── imgcore.h # ├── lib/ # │ ├── libimgcore.a # │ └── pkgconfig/ # │ └── imgcore.pc # └── share/ # 4. 验证沙箱中的程序能否运行（关键！） $HOME/staging/local/bin/imgproc --help # 应该正常输出帮助信息 # 5. 验证头文件和库是否可被其他项目使用 echo '#include <imgcore.h>' | gcc -I$HOME/staging/local/include -x c -c -o /dev/null - echo 'int main(){return 0;}' | gcc -L$HOME/staging/local/lib -limgcore -x c -o /dev/null -

DESTDIR的不可替代性：

• DESTDIR是make install的“虚拟根目录”。make install时，所有$(prefix)路径（如/usr/local）都会被自动替换为$(DESTDIR)$(prefix)（如/home/you/staging/usr/local）。这让你能在本地完全模拟rpm或deb包的安装行为。
• 没有DESTDIR，你就无法做make install后的自动化验证。make distcheck内部就是用DESTDIR来测试打包的完整性。
• DESTDIR和prefix是正交的。你可以./configure --prefix=/usr，然后make DESTDIR=/tmp/pkg install，最终文件会落在/tmp/pkg/usr/bin/下。这是构建Linux发行版软件包的标准流程。

4.5 发布：make distcheck——autotools的终极压力测试

make distcheck是autotools的“核武器”，它会自动完成：make dist→ 解压tarball →./configure→make→make check→make install→make installcheck→make clean。任何一步失败，整个发布就流产。

# 返回源码根目录（不是build目录！） cd ../ # 运行终极测试 make distcheck # 如果成功，会生成： # imgproc-1.0.0.tar.gz # 可发布的源码包 # imgproc-1.0.0/ # 解压后的临时目录，已通过全部测试

distcheck失败的三大高频原因及修复：

1. make check在临时目录失败：通常因为tests/目录下的测试数据文件没被EXTRA_DIST声明。修复：在tests/Makefile.am中添加EXTRA_DIST = test_data/。
2. make install后make installcheck失败：因为src/程序在安装后找不到libimgcore.so。修复：在src/Makefile.am中添加imgproc_LDFLAGS = -Wl,-rpath,$(libdir)，确保安装后的二进制自带rpath。
3. configure在临时目录找不到pkg-config模块：因为imgcore.pc没被pkgconfig_DATA声明，或pkgconfigdir路径错误。修复：检查lib/Makefile.am中pkgconfig_DATA和pkgconfigdir的定义，确保imgcore.pc被make dist打包。

我的个人体会是：make distcheck不是可选项，而是git push前的必检项。它能在你把代码推送到远程仓库前，就发现90%的跨平台兼容性问题。某次我提交了一个#include <sys/epoll.h>的补丁，本地make check完美通过，但make distcheck在macOS上失败——因为epoll是Linux特有。distcheck的沙箱环境，就是你的第一道跨平台防火墙。

5. 高级实战：解决多目录项目中那些“只可意会”的疑难杂症

autotools的文档号称“详尽”，但很多真实世界的问题，文档里只字未提。这些“灰色地带”的解决方案，才是十年老手和新手的本质区别。以下是我从十几个项目中提炼出的、最棘手也最实用的五类问题，每个都附带可直接粘贴的修复代码和原理剖析。

5.1 问题：子目录间有循环依赖，比如lib/需要src/里的工具生成头文件

场景：lib/中的core.c需要一个version.h，而version.h由src/目录下的gen_version