6、Makefile 基础：什么是 Makefile、Makefile 的基本规则、变量与自动推导、实战：为多模块项目编写 Makefile。
说实话，我见过太多 C 语言开发者，代码写得漂亮，但一到编译环节就抓瞎。每次改个文件，都要手动敲一串 gcc 命令。项目小还好说，一旦模块多起来，这种搞法就是灾难。
Makefile 就是来解决这个问题的。它本质上是一个自动化构建脚本，告诉编译器「哪些文件需要编译」「它们依赖谁」「怎么链接」。你只需要敲一个 make，剩下的它全包了。
什么是 Makefile？
Makefile 是 make 工具的配置文件。make 是一个自动化构建工具，它根据文件的时间戳来判断哪些文件需要重新编译。
我举个例子。你有一个项目，包含 main.c、utils.c、utils.h。你改了 utils.c，理论上只需要重新编译 utils.c，然后链接即可。但手动操作时，你很可能把整个项目全编译一遍——浪费时间。
Makefile 的核心理念就是：只编译需要编译的部分。它通过比较目标文件和依赖文件的时间戳，如果依赖比目标新，就重新生成目标。
一句话总结：Makefile 就是给项目写的一份「编译说明书」。make 工具照着说明书干活，省心省力。
Makefile 的基本规则
Makefile 的规则其实很简单，就一个公式：
目标: 依赖
命令目标通常是你要生成的文件（比如 .o 文件或可执行文件）。依赖是生成目标所需要的文件。命令是生成目标的具体操作。
注意：命令前面必须是一个 Tab 键，不能是空格。这个坑我踩过不止一次。
看个最简单的例子：
main: main.o utils.o
gcc -o main main.o utils.o
main.o: main.c utils.h
gcc -c main.c
utils.o: utils.c utils.h
gcc -c utils.c这个 Makefile 做了三件事：
- 最终目标
main依赖main.o和utils.o，链接它们生成可执行文件 main.o依赖main.c和utils.h，编译生成目标文件utils.o依赖utils.c和utils.h，编译生成目标文件
你执行 make 时，make 会先检查 main.o 和 utils.o 是否需要更新，然后再决定是否链接。如果你只改了 utils.c，那只有 utils.o 会重新编译，main.o 保持不变。
小技巧：我个人习惯把最终目标写在第一个规则里。因为 make 默认执行第一个目标。这样你只需要敲 make，不用指定目标名。
变量与自动推导
上面的 Makefile 有个问题——重复代码太多。每个 .o 文件的编译命令几乎一样，只是文件名不同。这时候就该变量出场了。
Makefile 的变量用 $() 或 ${} 引用，定义方式很简单：
CC = gcc
CFLAGS = -Wall -g
OBJS = main.o utils.o
main: $(OBJS)
$(CC) -o main $(OBJS)
main.o: main.c utils.h
$(CC) $(CFLAGS) -c main.c
utils.o: utils.c utils.h
$(CC) $(CFLAGS) -c utils.c这样改起来方便多了。想换编译器？改 CC 就行。想加编译选项？改 CFLAGS 就行。
但还能更省事。make 有自动推导功能，它知道怎么从 .c 文件生成 .o 文件。你只需要告诉它依赖关系：
CC = gcc
CFLAGS = -Wall -g
OBJS = main.o utils.o
main: $(OBJS)
$(CC) -o main $(OBJS)
main.o: utils.h
utils.o: utils.h看到没？我连编译命令都没写。make 会自动调用 $(CC) $(CFLAGS) -c main.c -o main.o。这就是自动推导的威力。
注意：自动推导只适用于标准的 .c 到 .o 的编译规则。如果你的编译过程有特殊操作（比如生成汇编文件、预处理文件），还是得手写命令。
常用的自动变量有这些：
| 变量 | 含义 | 示例 |
|---|---|---|
$@ |
目标文件名 | 在 main.o: main.c 中，$@ 就是 main.o |
$< |
第一个依赖文件名 | 在 main.o: main.c 中，$< 就是 main.c |
$^ |
所有依赖文件名（去重） | 在 main: main.o utils.o 中，$^ 就是 main.o utils.o |
用自动变量改写上面的 Makefile：
CC = gcc
CFLAGS = -Wall -g
OBJS = main.o utils.o
main: $(OBJS)
$(CC) -o $@ $^
main.o: utils.h
utils.o: utils.h这样写，就算以后加十个 .o 文件，也只需要改 OBJS 变量就行。
实战：为多模块项目编写 Makefile
好了，理论说完了。咱们来点实战。假设我有一个项目，目录结构如下：
project/
├── main.c
├── module_a/
│ ├── a.c
│ └── a.h
├── module_b/
│ ├── b.c
│ └── b.h
└── common/
├── log.c
└── log.h这是一个典型的多模块项目。每个模块有自己的源文件和头文件。我们需要一个 Makefile 来管理编译。
先定义目录变量：
CC = gcc
CFLAGS = -Wall -g -I. -Imodule_a -Imodule_b -Icommon
LDFLAGS =
SRC_DIRS = . module_a module_b common
SRCS = $(wildcard $(addsuffix /*.c, $(SRC_DIRS)))
OBJS = $(SRCS:.c=.o)
TARGET = app这里用了几个技巧：
wildcard函数：搜索所有目录下的 .c 文件addsuffix函数：给每个目录名加上/*.c$(SRCS:.c=.o)：把 .c 后缀替换成 .o
然后写编译规则：
$(TARGET): $(OBJS)
$(CC) -o $@ $^ $(LDFLAGS)
%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@
clean:
rm -f $(OBJS) $(TARGET)
.PHONY: clean这里 %.o: %.c 是模式规则，意思是「所有 .o 文件都依赖同名的 .c 文件」。这样不管有多少个模块，一条规则就搞定了。
完整的 Makefile 长这样：
CC = gcc
CFLAGS = -Wall -g -I. -Imodule_a -Imodule_b -Icommon
LDFLAGS =
SRC_DIRS = . module_a module_b common
SRCS = $(wildcard $(addsuffix /*.c, $(SRC_DIRS)))
OBJS = $(SRCS:.c=.o)
TARGET = app
$(TARGET): $(OBJS)
$(CC) -o $@ $^ $(LDFLAGS)
%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@
clean:
rm -f $(OBJS) $(TARGET)
.PHONY: clean核心思路：用 wildcard 自动收集源文件，用模式规则统一编译，用变量管理配置。这样不管项目怎么膨胀，Makefile 基本不用改。
我曾经接手过一个项目，Makefile 写了三百多行，每个 .o 文件都手写规则。我花了一天时间重构，缩到二十行。后来团队里新来的同事看到这个 Makefile，第一句话是：「原来 Makefile 可以这么清爽？」
嗯，这就是模块化编程的魅力——不仅代码要模块化，构建脚本也要模块化。
避坑指南：我曾经在 clean 规则上吃过亏。如果项目里恰好有一个叫 clean 的文件，make 会认为 clean 目标已经是最新的，不会执行清理操作。所以一定要加上 .PHONY: clean，告诉 make 这个目标不是文件。
最后，用一张图来总结 Makefile 的核心逻辑：
这张图把 Makefile 的执行流程讲得很清楚。你执行 make，它先检查目标文件是否存在、依赖是否更新，然后决定是重新编译还是跳过。最后把所有 .o 文件链接成可执行文件。
说白了，Makefile 就是一个「聪明」的编译脚本。它不比你手动编译快，但它知道什么时候该干活，什么时候该偷懒。这就是自动化构建的价值所在。