4、Makefile模式规则：%通配符的使用、静态模式规则、模式规则的优缺点

模式规则，说白了就是Makefile里的「偷懒神器」。

我刚开始写Makefile那会儿，每个目标文件都手写一条规则。项目小还好说，等源码文件一多，那叫一个痛苦。后来我师父丢给我一句话：「你试试%通配符，能省一半的代码。」

嗯，从那以后我就再也没手写过重复规则了。

先看一个最基础的例子。假设你有三个.c文件：main.c、utils.c、data.c，你想把它们都编译成.o文件。

新手写法是这样的：

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

utils.o: utils.c
    gcc -c utils.c -o utils.o

data.o: data.c
    gcc -c data.c -o data.o

你想想看，这要是100个文件，手写不得写到天亮？

用模式规则，一句话搞定：

%.o: %.c
    gcc -c $< -o $@

% 这个通配符，匹配的是文件名中「相同的那部分」。比如 main.o 和 main.c，% 匹配的就是 main。然后 $< 代表第一个依赖（也就是 %.c），$@ 代表目标（也就是 %.o）。

核心理解： % 不是正则表达式里的「任意字符」，它匹配的是「去掉后缀后的文件名主干」。同一个规则里，所有 % 都代表同一个字符串。

我在项目中遇到过一个问题：有人把 %.o: %.c 写成了 %o: %c，少了个点，结果规则死活不生效。嗯，这种细节坑过不少人。

模式规则虽然好用，但它有个问题——它会对所有匹配的文件生效。有时候你只想对「特定列表」里的文件应用规则，这时候就该静态模式规则上场了。

看个例子：

OBJS = main.o utils.o data.o

$(OBJS): %.o: %.c
    gcc -c $< -o $@

语法结构是：目标列表 : 模式 : 依赖模式

说白了就是：「我只管 OBJS 里列出来的这些文件，其他的别来烦我。」

我个人习惯在大型项目里用静态模式规则。为什么？因为更安全。你想想看，如果目录里不小心多了一个 test.c，普通模式规则会把它也编译进去，但静态模式规则不会——它只认你明确列出来的文件。

小技巧： 静态模式规则可以和 wildcard 函数配合使用，既灵活又可控：

SRCS = $(wildcard src/*.c)
OBJS = $(SRCS:.c=.o)

$(OBJS): %.o: %.c
    gcc -c $< -o $@

用了这么多年Makefile，我总结了一下模式规则的优缺点，给你做个参考。

我曾经在一个嵌入式项目里吃过亏。当时用了模式规则来编译所有.c文件，结果目录里有个 bootloader.c 也被编译进去了。那个文件需要特殊的编译参数，模式规则一视同仁，导致链接阶段报了一堆莫名其妙的错误。

从那以后，我养成了一个习惯：能用静态模式规则就别用普通模式规则。除非你非常确定目录里没有「不该被编译」的文件。

避坑指南： 我曾经遇到过 %.o: %.c 和 %.o: %.cpp 两条规则同时存在的情况。Make会优先使用第一条匹配的规则，而不是「最精确」的那条。所以如果你同时有C和C++源文件，最好用静态模式规则分别指定。

模式规则不止能处理 .c -> .o 这种简单情况。它还能做更多事情。

多目录编译：

obj/%.o: src/%.c
    gcc -c $< -o $@

这个规则把 src/ 下的源文件编译到 obj/ 目录下。% 匹配的是去掉目录和后缀后的文件名。

多后缀匹配：

%.o: %.c %.h
    gcc -c $< -o $@

这样写，只要头文件变了，对应的.o文件也会重新编译。嗯，虽然有点粗暴，但确实管用。

我个人建议：模式规则里依赖不要写太多。依赖越多，Make检查的时间越长。我一般只写直接依赖，头文件的依赖关系交给 gcc -MM 自动生成。

下面这张图帮你理清模式规则的核心逻辑：

模式规则这东西，用好了是神器，用不好是坑。我给你的建议是：从小项目开始练手，先写几个简单的模式规则，感受一下它的工作方式。等熟悉了，再往大型项目里用。

记住一点：Makefile的本质是「描述依赖关系」，不是「写脚本」。模式规则只是帮你更高效地描述这种关系而已。