第3章固件构建自动化

3、固件构建自动化：Makefile基础、CMake构建系统、CI/CD流水线集成

说到固件构建自动化，我脑子里第一个蹦出来的画面，是多年前那个深夜。

那时候我刚接手一个项目，固件编译全靠工程师手动敲命令。每次发布前，大家围在一台电脑前，像在搞某种神秘仪式。有人负责编译，有人负责打包，还有人负责祈祷——祈祷别出岔子。嗯，那场景，现在想想都觉得后怕。

后来我学乖了。自动化构建，说白了就是把「人肉操作」变成「机器干活」。你想想看，嵌入式开发本来就够复杂了，要是连编译打包这种重复劳动都不能自动化，那还谈什么效率？

3.1 Makefile基础：从手搓到半自动

Makefile这东西，我估计很多新手觉得它又老又土。但说实话，在嵌入式领域，它依然是绕不开的基础工具。为什么？因为轻量、直接、没有依赖。

我在项目中遇到过最典型的场景：一个STM32项目，源文件几十个，头文件路径一堆，链接脚本还得指定。如果每次都手动敲gcc命令，不出三天你准会疯掉。

一个典型的嵌入式Makefile骨架：

# 编译器设置
CROSS_COMPILE = arm-none-eabi-
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)ld
OBJCOPY = $(CROSS_COMPILE)objcopy

# 源文件
SRC = main.c uart.c spi.c flash.c
OBJ = $(SRC:.c=.o)

# 编译选项
CFLAGS = -mcpu=cortex-m4 -mthumb -O2 -Wall
LDFLAGS = -T linker.ld -nostartfiles

# 目标
TARGET = firmware.elf
BIN = firmware.bin

all: $(BIN)

$(BIN): $(TARGET)
	$(OBJCOPY) -O binary $< $@

$(TARGET): $(OBJ)
	$(LD) $(LDFLAGS) -o $@ $^

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

clean:
	rm -f $(OBJ) $(TARGET) $(BIN)

.PHONY: all clean

这段代码看着简单，但里面有几个坑，我一个个说。

变量定义：CROSS_COMPILE 这个变量，我建议一开始就定义好。换芯片平台时，改这一个地方就行。我曾经见过有人把编译器路径写死在每个规则里，后来换芯片，改到崩溃。
自动推导规则：%.o: %.c 这种模式规则，Make会自动匹配。但要注意，如果头文件有变化，Make不会自动重新编译。你需要手动添加依赖关系，或者用 -MMD 生成依赖文件。
.PHONY：这个一定要加。不加的话，如果当前目录下恰好有个叫 clean 的文件，make clean 就会说「文件已是最新」，然后什么都不做。嗯，我吃过这个亏。

我的习惯：在Makefile开头加一行 -include *.d，配合 -MMD 选项，自动追踪头文件依赖。这样改了头文件，Make会自动重新编译相关源文件，省心很多。

3.2 CMake构建系统：跨平台的现代方案

Makefile虽然好用，但项目一复杂，维护起来就头疼。尤其是当你需要支持多个芯片平台、多种编译选项时，Makefile会变得又臭又长。

这时候，CMake就派上用场了。我个人觉得，CMake最大的优势不是语法多漂亮，而是它把「构建逻辑」和「构建细节」分开了。你只需要描述「我要编译哪些文件、链接哪些库」，剩下的平台差异、编译器差异，CMake帮你搞定。

一个嵌入式CMake项目示例：

cmake_minimum_required(VERSION 3.15)
project(FirmwareProject C ASM)

# 设置目标芯片
set(MCU_FAMILY "STM32F4")
set(MCU_MODEL "STM32F407VG")

# 添加源文件
set(SOURCES
    src/main.c
    src/uart.c
    src/spi.c
    src/flash.c
    src/startup_stm32f407xx.s
)

# 添加头文件路径
target_include_directories(${PROJECT_NAME} PRIVATE
    inc/
    drivers/inc/
)

# 设置编译选项
target_compile_options(${PROJECT_NAME} PRIVATE
    -mcpu=cortex-m4
    -mthumb
    -O2
    -Wall
    -Wextra
)

# 生成二进制文件
add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD
    COMMAND ${CMAKE_OBJCOPY} -O binary ${PROJECT_NAME} firmware.bin
    COMMENT "Generating binary file"
)

你看，CMake的写法比Makefile更接近「人类语言」。而且它支持 out-of-source 构建，也就是在单独的目录里编译，不会把源文件目录搞得乱七八糟。

我在项目中遇到过一个问题：不同工程师的电脑上，工具链路径不一样。用Makefile的话，每个人都要改路径。用CMake就简单了，定义一个 toolchain.cmake 文件，大家共用，路径差异通过环境变量解决。

注意：CMake本身不编译代码，它只是生成构建文件（比如Makefile或Ninja文件）。所以你的电脑上还是要有对应的编译器。另外，CMake的语法有点「反人类」，尤其是变量作用域那块，建议多看官方文档。

3.3 CI/CD流水线集成：让机器替你打工

好了，现在你有了自动化的构建脚本。但每次发布固件，还是得有人去触发编译、打包、上传。能不能让这一切自动发生？

能。这就是CI/CD要做的事。

3.3.1 Jenkins：老牌劲旅

Jenkins我用了好多年。它最大的优点是灵活，几乎什么都能干。但缺点也很明显——配置起来像在写小说。

一个典型的Jenkins流水线，大概长这样：

pipeline {
    agent any

    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Build') {
            steps {
                sh 'make clean'
                sh 'make all'
            }
        }
        stage('Test') {
            steps {
                sh 'make test'
            }
        }
        stage('Package') {
            steps {
                sh './package.sh firmware.bin'
                archiveArtifacts artifacts: 'firmware.bin'
            }
        }
        stage('Deploy') {
            steps {
                sh 'scp firmware.bin user@ota-server:/firmware/'
            }
        }
    }
}

这段流水线做了几件事：拉代码、编译、测试、打包、部署。每一步都清晰可见。如果哪一步失败了，Jenkins会发邮件通知你。

我曾经在Jenkins上踩过一个坑：默认的工作空间清理策略。有一次我改了构建脚本，但Jenkins用了缓存，导致编译出来的固件还是旧的。后来我加了一行 cleanWs()，每次构建前清空工作空间，问题解决。

3.3.2 GitHub Actions：云原生新选择

如果你的代码托管在GitHub上，那GitHub Actions是个更轻量的选择。它不需要自己搭服务器，直接在GitHub的云端跑。

一个嵌入式固件的GitHub Actions配置：

name: Firmware CI

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3

    - name: Install ARM GCC
      run: |
        sudo apt-get update
        sudo apt-get install -y gcc-arm-none-eabi

    - name: Build Firmware
      run: |
        make clean
        make all

    - name: Run Unit Tests
      run: make test

    - name: Upload Artifact
      uses: actions/upload-artifact@v3
      with:
        name: firmware
        path: firmware.bin

你看，GitHub Actions的写法更简洁，而且和GitHub的集成度很高。每次push代码，自动触发构建。构建完的固件还能直接下载，或者自动发布到Release页面。

我的建议：小团队或个人项目，优先用GitHub Actions。省心，不用维护服务器。大团队或对安全性要求高的项目，用Jenkins，可以完全控制在自己的网络里。

3.4 避坑指南与最佳实践

做固件构建自动化这几年，我踩过的坑不少。挑几个典型的说说。

版本号管理：我曾经遇到过固件版本号写死在代码里，结果发布时忘了改，导致设备上报的版本号和实际不符。后来我改用Git tag + CI自动生成版本号，再也不用担心忘改了。
构建环境一致性：不同工程师的电脑上，编译器版本可能不一样。我建议用Docker容器来统一构建环境。把工具链、依赖库都装进容器里，大家用同一个镜像编译，保证结果一致。
增量编译 vs 全量编译：CI流水线里，我建议每次做全量编译。虽然慢一点，但能避免增量编译带来的「漏编译」问题。本地开发时可以用增量编译，节省时间。
固件签名：OTA升级的固件一定要签名。我见过有人直接把裸的bin文件丢到服务器上，结果被中间人篡改，设备刷了恶意固件。加个签名验证，成本不高，但安全提升一大截。

重要提醒：CI/CD不是银弹。它解决的是「重复劳动」的问题，但解决不了「代码质量」的问题。自动化构建之前，先确保你的代码能编译通过、逻辑正确。否则，你只是把错误更快地发布出去而已。

3.5 小结

固件构建自动化，说白了就是三件事：写脚本、配工具、连流水线。

Makefile是基础，CMake是进阶，CI/CD是最终形态。这三者不是互斥的，而是层层递进的关系。你可以从Makefile开始，慢慢过渡到CMake，最后接入CI/CD流水线。

我个人觉得，自动化构建最大的价值不是省时间，而是「确定性」。每次构建的结果都一样，不会因为操作人的不同而不同。这种确定性，在嵌入式开发中尤其重要——毕竟，你不想因为一次手误，让几千台设备变砖吧？

下一章，我们会聊聊OTA升级的具体实现。到时候，你会发现，没有自动化的构建流水线，OTA升级就是个空架子。

📚 课程目录

3、固件构建自动化：Makefile基础、CMake构建系统、CI/CD流水线集成

3.1 Makefile基础：从手搓到半自动

3.2 CMake构建系统：跨平台的现代方案

3.3 CI/CD流水线集成：让机器替你打工

3.3.1 Jenkins：老牌劲旅

3.3.2 GitHub Actions：云原生新选择

3.4 避坑指南与最佳实践

3.5 小结