Autoscan遗漏头文件检查：迁移项目至Autotools时配置脚本检测失效

这绝对是Autotools入门时最容易踩的坑之一——autoscan生成的configure.scan只是个基础模板，它的静态代码扫描能力相当有限，根本没法自动识别所有项目依赖的非系统库头文件，更别说帮你做完整的依赖校验了。你遇到的情况完全正常，接下来咱们一步步修复：

1. 手动添加头文件检测到configure.ac #

打开你从configure.scan改过来的configure.ac，找到合适的位置（比如在AC_PROG_CC之后），用AC_CHECK_HEADERS宏添加缺失的头文件检查。举个例子，如果你的项目依赖libbar的bar.h，就加：

AC_CHECK_HEADERS([bar.h], [], [AC_MSG_ERROR([Required header bar.h not found! Please install libbar development package.])])

这个宏的逻辑很简单：如果检测到bar.h存在，就继续；如果找不到，直接抛出错误提示，终止configure流程，不会让你走到编译阶段才踩坑。

2. 用pkg-config做完整的依赖检测（推荐） #

如果你的依赖库支持pkg-config（大部分现代库都支持），那直接用PKG_CHECK_MODULES宏会更省心——它不仅会检查头文件，还会验证库文件的存在和版本要求。比如依赖libfoo 1.0及以上版本，就加：

PKG_CHECK_MODULES([LIBFOO], [libfoo >= 1.0])

然后在你的Makefile.am里，把编译和链接参数用上：

AM_CFLAGS = $(LIBFOO_CFLAGS)
LDADD = $(LIBFOO_LIBS)

这样configure会自动处理所有依赖相关的编译和链接选项，比手动写头文件+库检查要靠谱得多。

3. 重新生成并验证configure脚本 #

修改完configure.ac后，用下面的命令重新生成全套Autotools文件：

autoreconf -vi

然后运行./configure，现在如果依赖的头文件或者库缺失，configure会立刻报错并给出清晰提示，不会再让你等到编译阶段才失败。

为啥autoscan会漏掉这些检查？ #

简单说就是autoscan的扫描逻辑太浅：它只会扫描源代码里直接出现的#include，如果头文件是通过条件编译引入的、或者嵌套在其他头文件里，它可能扫不到；另外，非系统标准库的头文件，autoscan默认不会标记为“必须依赖”，毕竟它没法判断哪些是项目核心依赖，哪些是可选的。

内容的提问来源于stack exchange，提问作者J. Doe