2. 构建系统入门

嵌入式Linux开发，说白了就是跟一堆代码、工具链、库文件打交道。你写好了驱动、调好了应用，总得有个东西把它们组织起来，编译成能在板子上跑起来的镜像吧？这个东西，就是构建系统。

我刚开始做嵌入式那会儿，觉得构建系统就是个「跑脚本」的活儿，没啥技术含量。直到有一次，我手动改了十几个Makefile变量，结果编译出来的内核死活起不来……嗯，从那以后，我再也不敢小看构建系统了。

这一章，咱们就聊聊构建系统的基础。我会从最底层的Makefile讲起，再到CMake，最后聊聊两个重量级的嵌入式构建框架——Buildroot和Yocto。你不需要一下子全记住，但得知道它们各自是干什么的，适合什么场景。

2.1 Makefile基础：一切构建的起点

Makefile，是Linux世界里最古老的构建工具之一。它定义了一套规则：什么文件依赖什么文件，用什么命令去编译。你只需要敲一个 make，它就能自动帮你搞定增量编译。

一个最简单的Makefile长这样：

hello: hello.c
    gcc -o hello hello.c

clean:
    rm -f hello

这里 hello 是目标（target），hello.c 是依赖（prerequisites），下面缩进的那行是命令（recipe）。注意，命令前面必须是一个Tab键，不能用空格。我见过不少新手在这上面栽跟头，包括我自己——有一次排查了半天，结果发现是编辑器把Tab自动转成了空格。

稍微复杂一点，我们会用到变量和自动变量：

CC = gcc
CFLAGS = -Wall -O2
TARGET = myapp
OBJS = main.o utils.o

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

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

clean:
    rm -f $(TARGET) $(OBJS)

这里 $@ 表示目标文件名，$^ 表示所有依赖文件，$< 表示第一个依赖文件。这些自动变量能省不少事。

我的习惯： 在嵌入式项目中，我通常会把交叉编译工具链单独定义成一个变量，比如 CROSS_COMPILE = arm-linux-gnueabihf-，然后 CC = $(CROSS_COMPILE)gcc。这样换平台时只需要改一个地方。

2.2 CMake基础：跨平台的现代选择

Makefile虽然强大，但跨平台时很痛苦。Windows、Linux、macOS的编译器、路径、库都不一样，你得写一堆条件判断。这时候，CMake就派上用场了。

CMake不直接编译代码，它先生成Makefile（或者Ninja、Visual Studio工程文件），然后再调用编译器。说白了，它是一个「元构建系统」。

一个简单的CMakeLists.txt：

cmake_minimum_required(VERSION 3.10)
project(MyApp)

set(CMAKE_C_STANDARD 99)
set(CMAKE_CXX_STANDARD 11)

add_executable(myapp main.c utils.c)
target_include_directories(myapp PRIVATE include)

然后执行：

mkdir build && cd build
cmake ..
make

CMake最让我喜欢的一点是，它支持「out-of-source build」——所有编译中间文件都放在 build 目录下，不会污染源码目录。这在嵌入式开发中特别有用，因为你可以为不同平台创建不同的build目录。

避坑指南： 我曾经在交叉编译时，忘记设置 CMAKE_TOOLCHAIN_FILE，结果CMake用了本机的gcc去编译ARM代码，链接时报了一堆莫名其妙的错误。记住，交叉编译一定要指定工具链文件。

2.3 Buildroot简介：小而美的构建系统

Buildroot，是我个人非常喜欢的一个嵌入式构建系统。它的核心理念是：给你一个配置文件，你告诉它用什么CPU、用什么内核版本、要哪些软件包，它就能自动下载、配置、编译，最终生成一个完整的根文件系统镜像、内核镜像和bootloader。

Buildroot的工作流程大致如下：

# 下载源码
git clone https://git.buildroot.net/buildroot
cd buildroot

# 配置
make menuconfig

# 编译
make

编译完成后，你会在 output/images 目录下看到 rootfs.tar、zImage、u-boot.bin 等文件。直接烧录到板子上就能跑。

Buildroot的优势在于：

  • 简单直接：配置项清晰，编译速度快
  • 体积小：生成的根文件系统可以做到几MB
  • 适合产品级：很多商业产品都在用

但它的缺点也很明显：不支持包管理，如果你想在运行时安装新软件，得重新编译整个系统。

注意： Buildroot默认会从网络下载源码包。如果你的开发环境不能联网，记得提前下载好所有包，放到 dl 目录下。我遇到过在客户现场没网，结果编译到一半卡住的尴尬情况。

2.4 Yocto简介：企业级的构建框架

Yocto，跟Buildroot走的是完全不同的路线。它更像一个「构建框架」，而不是一个「构建工具」。Yocto用BitBake作为任务调度引擎，用Recipe（配方）来描述每个软件包怎么编译、怎么安装。

一个典型的Yocto Recipe（.bb文件）长这样：

SUMMARY = "Hello World application"
LICENSE = "MIT"
SRC_URI = "file://hello.c"

S = "${WORKDIR}"

do_compile() {
    ${CC} ${CFLAGS} ${LDFLAGS} hello.c -o hello
}

do_install() {
    install -d ${D}${bindir}
    install -m 0755 hello ${D}${bindir}
}

Yocto的强大之处在于：

  • 高度可定制：几乎每一层都可以替换
  • 支持包管理：可以用opkg、rpm、deb等
  • 社区庞大：主流芯片厂商（NXP、TI、Xilinx）都提供BSP层

但代价是学习曲线陡峭。我第一次接触Yocto时，光是理解「Layer」、「Recipe」、「Class」、「Append」这些概念就花了一周。而且编译一次完整镜像，动辄几个小时。

我的建议： 如果你的团队有专职的构建工程师，产品需要频繁更新软件包，或者需要支持多种硬件变体，Yocto是更好的选择。如果只是做原型验证、小批量产品，Buildroot更省心。

2.5 选择适合项目的构建系统

那么问题来了：到底选哪个？

我根据实际项目经验，整理了一个对比表格：

维度 Makefile CMake Buildroot Yocto
学习成本 低 中 中 高
编译速度 快 快 中 慢
定制灵活性 高 高 中 极高
包管理 无 无 无 有
适用场景 小型项目、驱动模块 跨平台应用 产品级嵌入式系统 企业级、多变体产品

我个人习惯这样选：

  • 如果只是写一个驱动模块或者测试程序，直接用Makefile，简单粗暴。
  • 如果应用需要跨平台（比如同时支持Linux和Windows），用CMake。
  • 如果要做完整的嵌入式系统，且硬件固定、软件包不多，用Buildroot。
  • 如果产品线复杂、需要长期维护、支持OTA升级，用Yocto。

下面这张图，是我自己总结的构建系统选择决策流程：

开始选择构建系统 只需要编译单个模块/驱动？ 是 Makefile 否 需要跨平台？ 是 CMake 否 需要完整的根文件系统？ 否 Makefile/CMake 是 需要包管理/多变体？ 否 Buildroot 是 Yocto 决策流程：从简单到复杂，逐步选择最适合的构建系统

嗯，这张图基本概括了我的决策思路。你想想看，如果只是写个hello world，何必折腾Yocto呢？反过来，如果产品要卖到全球，要支持OTA、要兼容多个硬件版本，那Buildroot的简单模型就不够用了。

最后说一句： 没有「最好」的构建系统，只有「最合适」的。我见过有人用Yocto做了一个只跑两个进程的系统，也见过有人用Makefile维护了一个百万行代码的项目。工具是死的，人是活的。关键是理解每个工具的优缺点，然后根据项目实际情况做选择。

这一章的内容就到这里。构建系统是嵌入式Linux开发的基石，花点时间把基础打牢，后面会省很多事。

← 上一章 📖 返回目录 下一章 →