Makefile 与构建系统：从入门到实战

说到嵌入式开发，Makefile 是绕不开的一道坎。我见过不少工程师，代码写得漂亮，一碰到 Makefile 就头大。其实这东西没那么玄乎，说白了就是一个自动化构建的脚本。你告诉它「怎么编译、链接哪些文件」，它帮你干活。

我个人习惯把 Makefile 看作项目的「施工图纸」。图纸画得清楚，施工就顺畅。图纸乱画，后面全是坑。

Makefile 基础语法：三要素

一个最简单的 Makefile，核心就三样东西：目标、依赖、命令。

target: dependencies
    command

举个例子，编译一个 main.c：

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

这里 main 是目标，main.c 是依赖，gcc -o main main.c 是命令。注意命令前面必须是一个 Tab 键，不能用空格。我刚开始学的时候，被这个 Tab 坑了不下十次——明明看着对齐了，就是报错。后来养成习惯，每次写 Makefile 先敲 Tab。

变量与函数：让 Makefile 活起来

硬编码文件名？那是新手干的事。用变量，才是正经做法。

CC = gcc
CFLAGS = -Wall -O2
TARGET = app
SRCS = main.c utils.c

$(TARGET): $(SRCS)
    $(CC) $(CFLAGS) -o $@ $^

这里 $@ 代表目标名，$^ 代表所有依赖。我常用的自动变量还有 $<，表示第一个依赖。这些符号记牢了，写 Makefile 能省一半力气。

Makefile 里的函数也很实用。比如 wildcard 用来匹配文件：

SRCS = $(wildcard src/*.c)

再比如 patsubst 做模式替换，把 .c 换成 .o：

OBJS = $(patsubst %.c, %.o, $(SRCS))

你想想看，如果项目里有 50 个 .c 文件，手动写依赖得多痛苦？用函数，一行搞定。

自动依赖生成：别让头文件坑了你

嵌入式项目里，头文件改了，但 .c 文件没改，Makefile 会不会重新编译？默认不会。这就出问题了——你改了头文件里的宏定义，结果编译出来的还是旧代码。

解决办法是自动依赖生成。GCC 提供了 -MMD 选项，可以自动生成 .d 文件，里面记录了每个 .o 文件依赖哪些头文件。

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

-include $(wildcard *.d)

这样，头文件一改，对应的 .o 就会重新编译。我在一个 RTOS 项目里用过这个方案，再也没出现过「改了头文件忘了重编」的尴尬。

多目录项目管理：别把所有文件塞一个文件夹

项目大了，文件多了，全放一个目录？那是灾难。我见过一个项目，src 目录下 200 多个文件，找个头文件都要翻半天。

合理的做法是按功能分目录：

project/
├── src/
│   ├── main.c
│   ├── driver/
│   │   ├── uart.c
│   │   └── gpio.c
│   └── app/
│       └── task.c
├── inc/
│   ├── driver/
│   │   ├── uart.h
│   │   └── gpio.h
│   └── app/
│       └── task.h
└── Makefile

对应的 Makefile 怎么写？用递归 Makefile 或者单 Makefile 都行。我个人偏好单 Makefile，逻辑清晰，调试方便。

SRC_DIRS = src src/driver src/app
INC_DIRS = inc inc/driver inc/app

SRCS = $(foreach dir, $(SRC_DIRS), $(wildcard $(dir)/*.c))
OBJS = $(patsubst %.c, %.o, $(SRCS))
INC_FLAGS = $(addprefix -I, $(INC_DIRS))

$(TARGET): $(OBJS)
    $(CC) -o $@ $^

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

这里 foreach 遍历目录找文件，addprefix 给每个目录加 -I 前缀。嗯，这样写，目录再多也不怕。

CMake 入门与实战：告别手写 Makefile

手写 Makefile 虽然灵活，但跨平台时很麻烦。Linux 下用 GCC，Windows 下用 MSVC，ARM 下用交叉编译器……每个平台都得改。这时候 CMake 就派上用场了。

CMake 不直接编译，它生成 Makefile 或者 Ninja 构建文件。你写一份 CMakeLists.txt，它帮你适配不同平台。

一个最简单的 CMakeLists.txt：

cmake_minimum_required(VERSION 3.10)
project(MyProject)

set(CMAKE_C_STANDARD 11)

add_executable(app main.c utils.c)

编译步骤：

mkdir build
cd build
cmake ..
make

为什么要建 build 目录？这叫「外部构建」，生成的中间文件不会污染源码目录。我见过有人直接在源码目录跑 cmake，结果一堆 CMakeFiles 和 Makefile 混在代码里，看着就头疼。

CMake 的变量和函数也很强大。比如设置交叉编译：

set(CMAKE_C_COMPILER arm-none-eabi-gcc)
set(CMAKE_C_FLAGS "-mcpu=cortex-m4 -mthumb")

再比如添加头文件路径：

target_include_directories(app PRIVATE inc)

知识体系总览

下面这张图，把 Makefile 和 CMake 的核心知识点串起来了。你可以把它当作学习路线图。

实战对比：Makefile vs CMake

我的建议是：小项目或者快速验证，手写 Makefile 就够了。项目超过 10 个源文件，或者需要跨平台，果断上 CMake。别纠结，工具是为人服务的。