2. Yocto构建系统基础

要理解 Yocto 的构建性能与缓存优化，必须先看清它的构建系统骨架。Yocto 项目本身不是一个“发行版”，而是一套构建框架与协作规范；真正执行构建的是 BitBake，提供元数据与配方集合的是 OpenEmbedded（常以 meta 层形式存在），二者共同把“源码、配置、补丁、任务”组织成可复现的镜像。本节从对象、任务、依赖和流程四个角度建立整体认知。

一、核心对象：BitBake、元数据与配方

BitBake 是一个用 Python 实现的元数据解析与任务调度引擎，它读取配方（.bb）、追加文件（.bbappend）、类文件（.bbclass）和配置（.conf），生成一张巨大的任务依赖图，然后按依赖顺序并行执行。可以把它理解为“面向嵌入式构建的 Make 增强版”：Make 处理文件级依赖，BitBake 处理配方级、任务级和运行时级依赖。

元数据（Metadata）是 BitBake 的输入总称，主要包括：

• 配方 Recipe（.bb）：描述一个软件包如何获取、配置、编译、打包，例如 busybox_1.36.bb。
• 追加文件 .bbappend：在不修改原配方的前提下追加或覆盖变量，是层（Layer）定制的主要手段。
• 类文件 .bbclass：可复用的构建逻辑，如 autotools.bbclass、cmake.bbclass、kernel.bbclass。
• 配置文件 .conf：local.conf、distro.conf、machine.conf、bblayers.conf 决定机器、发行版与启用层。
• 包含文件 .inc：被多个配方共享的公共片段。

OpenEmbedded 提供的是“元数据生态”：大量基础配方、类文件和发行版策略。Yocto 则在其上提供参考发行版（Poky）、工具链（bitbake、devtool、oe-init-build-env）与发布流程。因此日常所说的“Yocto 构建”，本质是“BitBake 解析 OpenEmbedded 元数据并执行任务”。

二、任务与依赖关系

每个配方被拆解为一组标准任务，典型顺序为：do_fetch → do_unpack → do_patch → do_configure → do_compile → do_install → do_package → do_package_write_* → do_rootfs → do_image。任务之间通过 addtask、addtask ... after/before 建立顺序依赖，通过 DEPENDS、RDEPENDS、PROVIDES 建立配方级依赖。

依赖分为三类，理解它们对缓存优化至关重要：

• 构建依赖 DEPENDS：编译本配方前必须先构建完成的配方，影响任务图拓扑。
• 运行时依赖 RDEPENDS：打包进镜像后运行期需要的包，影响 rootfs 组装。
• 任务依赖：由 do_*[depends] 或 do_*[deptask] 声明的跨配方任务级依赖，例如内核与模块。

三、构建流程与数据流

一次完整构建的数据流可以概括为：解析配置 → 解析配方 → 生成任务依赖图 → 调度执行 → 产出包与镜像。下图展示了从元数据到最终镜像的关键对象与流向，其中缓存（sstate、下载缓存）在任务执行前被查询，命中则直接复用产物。

图中可以看到，缓存位于 BitBake 引擎与任务执行之间：每个任务执行前，BitBake 会根据输入（配方、变量、文件校验和）计算哈希，若 sstate-cache 中存在匹配产物，则直接解压复用，跳过实际编译。这正是后续章节优化构建时间的核心抓手。

四、典型场景与常见误区

假设我们要为一块 ARM 开发板构建带自定义应用的镜像，典型操作如下：

# 初始化构建环境
source oe-init-build-env build-arm

# 查看当前配置的机器与发行版
bitbake -e | grep -E '^MACHINE=|^DISTRO='

# 查看某配方的任务依赖图
bitbake -g busybox && cat task-depends.dot

# 只执行到编译阶段，便于调试
bitbake -c compile busybox

# 强制重新执行某任务（忽略缓存）
bitbake -c compile -f busybox

# 查看任务执行时间，定位耗时任务
bitbake -p -n busybox

常见误区与复盘要点：