4. 变量与宏的合理使用：避免硬编码，提升可维护性
说实话，我见过太多 Makefile 里写满了魔法数字和路径字符串。项目刚起步时还好，等代码量一上来，改一个路径要翻遍整个文件，那感觉……嗯，就像在草堆里找一根针。今天我们就聊聊怎么用变量和宏，把 Makefile 从「一次性脚本」变成「可维护的工程配置」。
4.1 为什么硬编码是万恶之源？
先看一个反面教材。这是我早期接手的一个项目，Makefile 长这样：
# 反面教材：硬编码地狱
all:
gcc -I/usr/local/include -L/usr/local/lib -lmylib src/main.c src/utils.c -o build/app
clean:
rm -f build/app build/*.o
install:
cp build/app /usr/local/bin/
你发现问题了吗？路径、编译器、库名、输出目录……全是写死的。如果哪天库路径变了，或者想换个编译器，你得改多少个地方？我数了数，至少 5 处。更可怕的是，这种 Makefile 没法复用——换个项目就得重写。
核心原则：任何出现超过一次的值，都应该定义为变量。任何可能变化的值，都应该定义为变量。
4.2 变量定义：从「写死」到「配置化」
我个人习惯把变量分成几类，这样结构清晰，后期维护也方便。你想想看，如果所有变量都堆在一起，找起来多费劲。
| 变量类别 | 示例 | 说明 |
|---|---|---|
| 路径变量 | SRC_DIR := src |
所有目录路径 |
| 工具变量 | CC := gcc |
编译器、链接器等 |
| 标志变量 | CFLAGS := -Wall -O2 |
编译/链接选项 |
| 目标变量 | TARGET := app |
最终生成的文件名 |
改造后的 Makefile 是这样的：
# 变量定义区
CC := gcc
CFLAGS := -Wall -O2 -I/usr/local/include
LDFLAGS := -L/usr/local/lib -lmylib
SRC_DIR := src
BUILD_DIR := build
TARGET := $(BUILD_DIR)/app
SRCS := $(wildcard $(SRC_DIR)/*.c)
OBJS := $(SRCS:$(SRC_DIR)/%.c=$(BUILD_DIR)/%.o)
# 规则区
all: $(TARGET)
$(TARGET): $(OBJS)
$(CC) $^ -o $@ $(LDFLAGS)
$(BUILD_DIR)/%.o: $(SRC_DIR)/%.c | $(BUILD_DIR)
$(CC) $(CFLAGS) -c $< -o $@
$(BUILD_DIR):
mkdir -p $@
clean:
rm -rf $(BUILD_DIR)
install: $(TARGET)
cp $< /usr/local/bin/
看到了吗？现在要改编译器，只需要改 CC 那一行。要改输出目录，改 BUILD_DIR 就行。我在项目中遇到过最爽的一次，客户要求把整个项目从 Linux 移植到 macOS，我只改了 3 个变量就搞定了。
4.3 变量的赋值方式：= vs := vs ?= 的区别
这个坑我踩过好几次。Makefile 里变量赋值有好几种方式，用错了会出大问题。
- =：递归展开赋值。变量在使用时才展开，可以引用后面定义的变量。
- :=：简单赋值。变量在定义时立即展开，后面的变量引用无效。
- ?=：条件赋值。只有变量未定义时才赋值，常用于提供默认值。
举个例子你就明白了：
# 递归展开
A = $(B)
B = hello
# 使用 A 时，A 的值是 "hello"
# 简单赋值
A := $(B)
B = hello
# A 的值是 ""（因为定义时 B 还没定义）
# 条件赋值
CC ?= gcc
# 如果环境变量 CC 已设置，则使用环境变量的值
我曾经踩过的坑：用 = 定义了一个变量，结果在循环里每次展开都重新计算，导致性能极差。后来改成 := 就解决了。所以我的建议是：能用 := 就用 :=，除非你明确需要延迟展开。
4.4 宏与函数：让 Makefile 具备「编程能力」
变量只能存数据，宏和函数才能处理逻辑。GNU Make 提供了丰富的内置函数，我常用的有这些：
| 函数 | 用途 | 示例 |
|---|---|---|
wildcard |
匹配文件 | $(wildcard src/*.c) |
patsubst |
模式替换 | $(patsubst %.c,%.o,$(SRCS)) |
foreach |
循环处理 | $(foreach dir,$(DIRS),$(wildcard $(dir)/*.c)) |
filter |
过滤匹配 | $(filter %.h,$(FILES)) |
更高级的用法是自定义宏。说白了，就是把一段重复的逻辑封装起来：
# 定义一个编译宏
define compile_c
$(BUILD_DIR)/$(1).o: $(SRC_DIR)/$(1).c
$(CC) $(CFLAGS) -c $$< -o $$@
endef
# 使用宏
$(eval $(call compile_c,main))
$(eval $(call compile_c,utils))
你想想看，如果项目有 50 个源文件，用宏生成规则比手写 50 条规则要省多少事？我在一个嵌入式项目里用过这个技巧，Makefile 从 300 行缩减到了 80 行。
4.5 实战：构建一个可配置的构建系统
好了，理论说完了，我们来看一个完整的例子。这是一个支持多平台、多配置的 Makefile 框架：
# ============================================
# 可配置构建系统
# ============================================
# 平台检测
UNAME := $(shell uname)
# 平台相关配置
ifeq ($(UNAME),Linux)
CC := gcc
CFLAGS := -Wall -O2 -DLINUX
LDFLAGS := -lm
else ifeq ($(UNAME),Darwin)
CC := clang
CFLAGS := -Wall -O2 -DMACOS
LDFLAGS := -framework CoreFoundation
endif
# 构建配置（支持 Debug/Release）
BUILD_TYPE ?= release
ifeq ($(BUILD_TYPE),debug)
CFLAGS += -g -DDEBUG
else
CFLAGS += -O2 -DNDEBUG
endif
# 目录结构
SRC_DIR := src
BUILD_DIR := build/$(BUILD_TYPE)
TARGET := $(BUILD_DIR)/app
# 自动收集源文件
SRCS := $(wildcard $(SRC_DIR)/*.c)
OBJS := $(SRCS:$(SRC_DIR)/%.c=$(BUILD_DIR)/%.o)
# 默认目标
all: $(TARGET)
# 链接
$(TARGET): $(OBJS)
$(CC) $^ -o $@ $(LDFLAGS)
# 编译
$(BUILD_DIR)/%.o: $(SRC_DIR)/%.c | $(BUILD_DIR)
$(CC) $(CFLAGS) -c $< -o $@
$(BUILD_DIR):
mkdir -p $@
# 清理
clean:
rm -rf build
# 安装
PREFIX ?= /usr/local
install: $(TARGET)
cp $< $(PREFIX)/bin/
.PHONY: all clean install
我的经验之谈：变量名最好用大写，这样一眼就能看出是 Makefile 变量，而不是 shell 变量。另外，给变量加注释是个好习惯——三个月后的你一定会感谢现在的你。
4.6 知识体系总览
下面这张图总结了本章的核心逻辑。说白了，变量和宏就是 Makefile 的「抽象层」，把变化的部分隔离出来，让不变的部分保持稳定。
嗯，总结一下。变量和宏的核心价值就四个字：避免重复。把硬编码变成变量，把重复逻辑变成宏，你的 Makefile 就能从「一次性脚本」进化成「可维护的工程配置」。下次改路径、换编译器、加新模块的时候，你会感谢今天做的这些抽象。