16. Automake语法：Makefile.am编写、bin_PROGRAMS/lib_LIBRARIES、SOURCES/CFLAGS/LDADD、递归与非递归构建
好，咱们今天聊聊Automake。说实话，Autotools这套工具链里，Automake是最容易让人「一看就懂，一写就废」的。为什么？因为它的语法太像Makefile了，但又不完全是。你按Makefile的思路写，八成会踩坑。
我个人习惯把Automake看作一个「Makefile生成器」。你写一个Makefile.am，它帮你生成完整的Makefile.in，再配合configure脚本，最终产出真正的Makefile。这个流程听起来绕，但用顺手了，跨平台编译真的省心。
16.1 核心变量：bin_PROGRAMS 和 lib_LIBRARIES
这两个变量是Automake的入口。说白了，你告诉Automake：「我要编译什么？」
- bin_PROGRAMS：要生成的可执行文件，安装到
/usr/bin或/usr/local/bin。 - lib_LIBRARIES：要生成的静态库（
.a文件），安装到/usr/lib或/usr/local/lib。
命名规则很简单：安装目录_文件类型。比如bin_PROGRAMS、lib_LIBRARIES、include_HEADERS。你想想看，这个命名方式是不是很直观？
重要提醒：变量名中的「PROGRAMS」和「LIBRARIES」都是复数。少写一个S，Automake会报错。我当年因为这个错误排查了半小时，后来发现是拼写问题。
# 一个简单的例子
bin_PROGRAMS = hello
hello_SOURCES = hello.c main.c
hello_CFLAGS = -Wall -O2
hello_LDADD = -lm看到没？每个目标文件（比如hello）都有对应的_SOURCES、_CFLAGS、_LDADD变量。这种「目标_属性」的命名方式，是Automake的核心语法。
16.2 SOURCES、CFLAGS、LDADD 的用法
这三个变量是编译的核心配置。咱们一个一个说。
SOURCES：源文件列表
这个最简单。把你所有的.c、.cpp、.h文件列出来就行。注意，头文件也要列进去，虽然编译时不一定用到，但Automake需要知道依赖关系。
hello_SOURCES = hello.c main.c utils.h我曾经遇到过一个坑：忘了列头文件，结果修改头文件后，make不会重新编译。嗯，这里要注意，Automake的依赖追踪依赖你列出的源文件。
CFLAGS：编译选项
这里可以加-I、-D、-Wall等选项。但要注意，全局的编译选项用AM_CFLAGS，目标专用的用hello_CFLAGS。两者可以同时存在，Automake会合并它们。
个人经验：我习惯把通用的-Wall -Wextra放在AM_CFLAGS里，把特定库的-I路径放在目标专用的_CFLAGS里。这样模块化更清晰。
LDADD：链接选项
这个变量指定链接时需要的库。比如-lm（数学库）、-lpthread（线程库）。如果是自己编译的库，可以用hello_LDADD = ../lib/libfoo.a。
hello_LDADD = -lm -lpthread注意，LDADD是全局的链接选项，如果某个目标需要特殊的链接库，用目标_LDADD覆盖。
16.3 递归构建 vs 非递归构建
这是个大话题。简单说，递归构建就是每个子目录有自己的Makefile.am，父目录通过SUBDIRS变量引用子目录。非递归构建则是所有源文件都在一个Makefile.am里管理。
递归构建：传统方式
大多数开源项目都用这种方式。结构清晰，每个模块独立。
# 顶层 Makefile.am
SUBDIRS = src lib tests
# src/Makefile.am
bin_PROGRAMS = myapp
myapp_SOURCES = main.c foo.c递归构建的好处是模块化强，每个子目录可以独立编译。但缺点也很明显：编译速度慢，因为每个子目录都要启动一次make。我参与过一个大型项目，递归构建的编译时间有40%花在make进程的启动上。
非递归构建：现代方式
把所有源文件放在一个Makefile.am里，用相对路径引用。
# 顶层 Makefile.am
bin_PROGRAMS = myapp
myapp_SOURCES = src/main.c src/foo.c lib/bar.c非递归构建的编译速度更快，因为只有一个make进程。但缺点也很明显：Makefile.am会变得非常庞大，难以维护。我个人建议：小项目（少于20个源文件）用非递归，大项目用递归。
避坑指南：我曾经在一个中型项目里强行使用非递归构建，结果Makefile.am写了800多行，每次修改都要小心翼翼。后来改成递归构建，虽然编译慢了10%，但维护成本降低了60%。所以，不要盲目追求「非递归」，适合的才是最好的。
16.4 知识体系图
下面这张图展示了Automake的核心语法和构建模式的关系。你可以看到，从Makefile.am出发，通过核心变量定义目标，再选择递归或非递归的构建方式，最终生成可执行文件或库。
16.5 实战建议
最后，我分享几个实战中的小技巧：
- 变量命名要一致：
bin_PROGRAMS里写了myapp，那么对应的变量必须是myapp_SOURCES，不能写成myapp_SRC。Automake对命名非常严格。 - 善用
AM_CPPFLAGS：如果多个目标都需要同一个-I路径，用AM_CPPFLAGS统一设置，避免重复。 - 递归构建时注意
SUBDIRS顺序：如果lib依赖src，那么SUBDIRS里src要写在lib前面。Automake会按顺序编译。 - 非递归构建时用
noinst_LIBRARIES：如果库只在项目内部使用，不需要安装到系统目录，用noinst_LIBRARIES代替lib_LIBRARIES。
一个小技巧：如果你不确定某个变量怎么写，可以运行automake --help查看文档。或者直接看GNU项目的Makefile.am，比如coreutils、binutils，它们的写法非常规范。
好了，Automake的语法核心就这些。说白了，就是记住「目标_属性」的命名规则，然后根据项目规模选择递归或非递归构建。写多了自然就熟练了。
公众号:蓝海资料掘金营，微信deep3321