📚 课程目录第2章规则与目标

规则与目标：深入理解 Makefile 的核心——规则、目标、依赖与命令

说实话，我见过不少工程师写 Makefile，就是照着网上抄一段。能用，但出了问题就抓瞎。为什么？因为没搞懂 Makefile 最核心的东西——规则。

规则就是 Makefile 的命根子。你写一百行还是写一万行，底层逻辑都是它。今天咱们就把这个根刨出来，看个清清楚楚。

一条规则，到底长什么样？

先看最基础的形式：

目标: 依赖
    命令

就这么三部分。我当年刚入行时觉得这也太简单了，结果第一次写多文件工程就栽了跟头。嗯，咱们一个一个拆开说。

组成部分	含义	我踩过的坑
目标（target）	要生成的文件，或者一个"伪"动作名	目标名跟文件名冲突，Make 死活不执行
依赖（prerequisites）	生成目标所依赖的文件或其他目标	漏写头文件依赖，改完 .h 不重新编译
命令（recipe）	如何从依赖生成目标的具体 shell 指令	命令前没加 Tab，Make 直接报错

血的教训：命令前面必须是 Tab 键，不是空格！我曾经因为这个低级错误，排查了整整一下午。编辑器把 Tab 自动转成空格了，Make 翻脸不认人。

目标：不只是文件名那么简单

目标分两种：文件目标和伪目标。

文件目标好理解——就是要生成的那个文件。比如 main.o、app。Make 会检查这个文件是否存在，以及它的时间戳是否比依赖旧。

伪目标就有点意思了。它不代表真实文件，只是一个"动作名"。比如：

.PHONY: clean
clean:
    rm -f *.o app

为什么要有 .PHONY？我遇到过这种情况：项目目录里有个叫 clean 的文件夹，结果执行 make clean 时，Make 发现"目标已存在，不需要执行"。你说气不气人？

我的习惯：所有非文件目标，一律声明为 .PHONY。包括 clean、all、install、test。这能避免 99% 的"目标已存在"陷阱。

依赖：Makefile 的"智能"就靠它

依赖是 Makefile 最精妙的设计。你想想看，Make 怎么知道哪些文件需要重新编译？靠的就是依赖关系和时间戳比较。

举个例子：

app: main.o utils.o
    gcc -o app main.o utils.o

main.o: main.c defs.h
    gcc -c main.c

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

这里有个链条：

如果你改了 defs.h，Make 发现 main.o 的依赖比它旧，于是重新编译 main.o
然后发现 app 的依赖 main.o 更新了，于是重新链接 app
utils.o 没受影响，跳过

这就是增量编译的精髓。只编译需要编译的部分，大型项目能省下大量时间。

  核心逻辑：Make 的决策树只有三步——

目标文件是否存在？不存在 → 执行命令

依赖文件是否有更新？有更新 → 执行命令

以上都不满足 → 跳过，什么都不做

命令：藏在 Tab 后面的细节

命令部分有几个容易忽略的点，我一个个说。

第一，每条命令都在独立的 shell 中执行。 这意味着：

target:
    cd src
    gcc -c main.c    # 这行不在 src 目录下执行！

为什么？因为 cd src 在子 shell 里执行完了，下一行又回到当前目录。解决办法是用 && 连接，或者写成一行：

target:
    cd src && gcc -c main.c

第二，命令前的 @ 符号。 加上它，Make 执行时不会回显这条命令。我习惯在 echo 和清理命令前加 @：

clean:
    @echo "Cleaning..."
    @rm -f *.o app

第三，命令前的 - 符号。 告诉 Make：这条命令即使执行失败，也继续往下走。比如删除不存在的文件：

clean:
    -rm -f *.o app   # 没有 .o 文件也不会报错退出

一张图看懂规则体系

下面这张图，是我给团队新人培训时画的。它把 Makefile 规则的核心逻辑串起来了：

多目标与多依赖

实际项目中，一条规则往往不止一个目标或一个依赖。看这个例子：

main.o utils.o: defs.h
    # 这条规则的意思是：只要 defs.h 变了，main.o 和 utils.o 都得重新编译

这种写法在头文件依赖管理里特别有用。我习惯把公共头文件放在这种多目标规则里，省得每个 .o 文件单独写一遍。

依赖也可以写多个：

main.o: main.c defs.h config.h
    gcc -c main.c

这里 main.o 依赖三个文件。任何一个变了，都会触发重新编译。

自动变量：少写重复代码

写规则时，最烦的就是在命令里重复目标名和依赖名。Make 提供了一组自动变量，专门解决这个问题：

变量	含义	示例值
`$@`	目标文件名	`main.o`
`$<`	第一个依赖文件名	`main.c`
`$^`	所有依赖文件列表（去重）	`main.c defs.h`
`$?`	比目标新的依赖文件列表	`defs.h`
`$*`	目标文件名去掉后缀的部分	`main`

用自动变量改写上面的例子：

main.o: main.c defs.h
    gcc -c $< -o $@

这比写死文件名灵活多了。我后来做大型项目，所有编译规则都统一用自动变量，复制粘贴改起来特别方便。

我的习惯：只要规则里有多个文件，就用自动变量。一来减少手误，二来规则更通用。你想想看，如果以后改了文件名，难道还要一条条去改命令吗？

规则匹配：模式规则与静态模式规则

如果每个 .c 文件都要写一条规则，那 Makefile 得写到猴年马月。模式规则就是用来干这个的：

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

这条规则匹配所有 .o 目标。只要 Make 需要生成 xxx.o，它就去找 xxx.c，然后用这条规则编译。

静态模式规则更精确一点——只对指定的目标列表生效：

objects = main.o utils.o

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

这里只有 main.o 和 utils.o 会匹配这条规则，其他 .o 文件不受影响。

规则的搜索路径：VPATH 和 vpath

多目录工程里，源文件分散在不同文件夹。Make 默认只在当前目录找依赖。怎么办？

VPATH 变量：指定全局搜索路径

VPATH = src:lib

Make 会在当前目录、src 目录、lib 目录依次查找依赖文件。

vpath 指令：更精细的模式匹配

vpath %.c src
vpath %.h include

这条指令告诉 Make：.c 文件去 src 找，.h 文件去 include 找。我在实际项目中更常用 vpath，因为它不会让 Make 盲目搜索所有目录。

注意：VPATH 只影响依赖文件的查找，不影响目标文件的生成位置。目标文件默认还是生成在当前目录。如果你想让目标文件也分散到不同目录，需要在目标名里带上路径，比如 build/main.o。

规则的执行顺序

Make 默认执行 Makefile 中第一条规则的目标。所以习惯上，第一条规则都是 all：

all: app test

这样执行 make 不带参数时，就会构建 app 和 test 两个目标。

规则的执行顺序还有几个要点：

Make 会先递归构建依赖，再构建当前目标（深度优先）
同一目标的多个规则，Make 会合并它们的依赖列表
如果同一个目标出现多次且都有命令，只有最后一条规则的命令生效

最后这点我吃过亏。有一次我在 Makefile 里写了两个 clean 规则，一个在前面删 .o 文件，一个在后面删可执行文件。结果前面的命令被覆盖了，只执行了后面的。从那以后，我每个目标只写一条规则，绝不分散。

小结

规则是 Makefile 的骨架。搞懂了规则，你就掌握了 Make 的思维方式。记住三个核心：

目标——要什么
依赖——凭什么
命令——怎么干

后面的章节，咱们会在这个基础上搭建真正的多目录工程。到时候你会发现，今天打的地基越扎实，后面盖楼就越顺手。