第三章 隐式规则：Make的隐式规则链、模式匹配规则、如何禁用隐式规则

说实话，我刚接触Makefile那会儿，最让我头疼的就是隐式规则。你写了个简单的编译命令，Make却自作主张帮你干了一堆事。有时候它帮了大忙，有时候却把你坑得欲哭无泪。今天咱们就把这块彻底掰扯清楚。

3.1 隐式规则的本质

隐式规则，说白了就是Make内置的一套“猜你心思”的规则。当你没有显式写出某个目标的构建方法时，Make会尝试用内置规则去推导。我个人习惯把这种机制叫做“Make的自动补全”。

举个例子，你写了个最简单的Makefile：

hello: hello.o
    gcc -o hello hello.o

你并没有告诉Make怎么把hello.c变成hello.o，但Make会自动调用gcc -c hello.c -o hello.o。这就是隐式规则在起作用。

3.2 隐式规则链

隐式规则不是孤立的，它们会形成一条链。我记得有一次在项目中，我写了个目标依赖main.o，Make自动找到了main.c，然后又发现main.c依赖main.y，于是它先调用yacc生成main.c，再编译成main.o。这就是隐式规则链。

常见的隐式规则链包括：

• C语言链：.c → .o → 可执行文件
• Yacc/Lex链：.y → .c → .o；.l → .c → .o
• 汇编链：.s → .o
• Fortran链：.f → .o

你想想看，如果Make没有这套链式推导，你得写多少重复的规则？但问题也来了——链式推导有时候会出乎你的意料。

3.3 模式匹配规则

隐式规则的核心是模式匹配。Make使用%作为通配符，匹配任意字符串。比如：

%.o: %.c
    $(CC) -c $(CFLAGS) $< -o $@

这条规则的意思是：任何.o文件，如果存在同名的.c文件，就用这条命令来编译。这里的%匹配了文件名中相同的部分。

Make内置了很多这样的模式规则。你可以用make -p命令查看所有内置规则。我个人建议你至少跑一次这个命令，看看Make到底内置了多少规则——你会惊讶的。

3.4 如何禁用隐式规则

有时候隐式规则反而碍事。比如你有个clean目标，Make却试图去找clean.c来编译。这时候就需要禁用隐式规则了。

禁用方法有三种：

1. 使用空规则：写一条没有命令的规则，比如%.o: %.c，这会覆盖内置规则但不执行任何操作。
2. 使用.SUFFIXES：清空后缀列表.SUFFIXES:，这会禁用所有基于后缀的隐式规则。
3. 使用MAKEFLAGS：在命令行加-r或--no-builtin-rules选项。

我个人最常用的是第二种：

.SUFFIXES:
.SUFFIXES: .c .o .h    # 只保留需要的后缀

嗯，这里要注意：清空.SUFFIXES只会禁用基于后缀的规则，不会禁用模式规则。如果你想彻底禁用所有内置规则，用make -r最干脆。

3.5 隐式规则链的优先级

Make在匹配隐式规则时是有优先级的。它按照规则定义的顺序来尝试匹配。内置规则中，越具体的规则优先级越高。比如：

• %.o: %.c 比 %.o: %.y 优先级高（如果两者都存在）
• 用户定义的规则优先级高于内置规则
• 短链规则优先级高于长链规则

为什么会这样？因为Make会优先选择“代价最小”的路径。它先尝试一步就能完成的规则，不行再尝试两步的链式推导。

main.o: main.c
    gcc -c main.c -o main.o

3.6 隐式规则与变量

隐式规则中大量使用了变量。比如CC、CFLAGS、LDFLAGS等。你可以通过修改变量来定制隐式规则的行为。

我记得有个项目需要交叉编译，我只需要设置：

CC = arm-linux-gnueabihf-gcc
CFLAGS = -march=armv7-a -mfpu=neon

所有隐式规则就自动适配了交叉编译环境。这就是变量的威力。

3.7 隐式规则链的调试

当隐式规则不按你预期工作时，调试起来很头疼。我常用的调试方法：

1. make -p：打印所有规则和变量定义
2. make -d：打印调试信息，包括Make尝试了哪些规则
3. make --trace：打印每条规则的执行原因

有一次我死活想不通为什么Make不编译某个文件，用make -d一看，原来是因为那个文件的时间戳比目标文件旧，Make认为不需要重新编译。嗯，这种问题光靠猜是猜不出来的。

这张图把隐式规则的三个核心维度串起来了。左边是规则链，中间是模式匹配，右边是禁用方法。你想想看，掌握了这三块，隐式规则对你来说就不再是黑盒了。