4. Yocto构建流程

Yocto 项目并不是一个“一键编译”的脚本集合，而是一套以 BitBake 为调度核心、以元数据（Metadata）为输入、以任务（Task）为执行单元的构建系统。理解 Yocto 构建流程，关键要抓住五条主线：配方（Recipe）描述“做什么”，任务（Task）定义“怎么做”，依赖解析决定“按什么顺序做”，构建目录（Build Directory）承载“在哪里做”，而镜像与 SDK 则是“最终交付什么”。本节将沿着一次典型构建的推进顺序，把这五条主线串成一条完整链路。

一、核心原理：从元数据到产物的分层模型

Yocto 的构建输入统称为元数据，主要包括三类：配方（.bb / .bbappend）、配置（local.conf、bblayers.conf、distro.conf、machine.conf）以及类（.bbclass）。配方描述一个软件包的来源、版本、许可证、依赖和安装规则；类提供可复用的构建逻辑；配置则决定目标架构、发行版特性、镜像内容等全局参数。

BitBake 读取这些元数据后，会为每个配方生成一组任务，并构建一张任务依赖图（Task Dependency Graph）。这张图不仅包含配方之间的 DEPENDS、RDEPENDS 关系，还包含任务之间的先后约束，例如 do_fetch 必须先于 do_unpack，do_compile 必须先于 do_install。BitBake 依据这张图进行拓扑排序，决定哪些任务可以并行执行、哪些必须等待。

一句话理解：配方是“菜谱”，任务是“做菜的步骤”，依赖解析是“安排灶台和顺序”，构建目录是“厨房”，镜像和 SDK 是“端上桌的菜”和“可复用的厨具包”。

二、方法流程：一次完整构建的推进顺序

下面以构建一个最小镜像并导出 SDK 为例，梳理标准流程。

  1. 初始化构建环境：执行 source oe-init-build-env build，脚本会创建或进入构建目录，并生成 conf/local.conf 与 conf/bblayers.conf。
  2. 配置目标与层：在 local.conf 中设置 MACHINE、DISTRO，在 bblayers.conf 中加入 meta、meta-poky、meta-yocto-bsp 等层。
  3. 解析配方与依赖：BitBake 扫描所有层中的配方，计算 PROVIDES、DEPENDS、RDEPENDS，生成任务依赖图。
  4. 执行任务链：按依赖顺序执行 do_fetch、do_unpack、do_patch、do_configure、do_compile、do_install、do_package 等任务。
  5. 生成镜像：通过 do_rootfs 组装根文件系统，再由 do_image_* 生成 .wic、.ext4、.tar.bz2 等格式。
  6. 生成 SDK：执行 bitbake core-image-minimal -c populate_sdk，产出交叉工具链、sysroot 和环境设置脚本。
# 典型构建命令
source oe-init-build-env build
bitbake core-image-minimal
bitbake core-image-minimal -c populate_sdk

# 查看任务依赖图（需 graphviz）
bitbake -g core-image-minimal
cat task-depends.dot | head -n 20

三、关键环节：任务、依赖与构建目录

任务（Task）是 BitBake 的最小执行单元。每个配方默认继承 base.bbclass，获得一组标准任务。开发者可以通过 do_compile()、do_install() 等函数覆盖默认行为，也可以用 addtask 添加自定义任务。

依赖解析分为构建时依赖和运行时依赖。构建时依赖由 DEPENDS 声明，决定编译顺序；运行时依赖由 RDEPENDS 声明，决定镜像中包的安装关系。BitBake 还会处理 PROVIDES 和虚拟配方（如 virtual/kernel），使同一依赖可以由不同配方满足。

构建目录是 Yocto 的工作区，典型结构如下：

目录/文件作用
conf/local.conf本地构建配置，如 MACHINE、DISTRO、并行度
conf/bblayers.conf声明参与构建的层
tmp/work/各配方的工作目录，含源码、编译、安装中间产物
tmp/deploy/images/最终镜像、内核、设备树等交付物
tmp/deploy/sdk/生成的 SDK 安装包
tmp/sstate-cache/共享状态缓存，加速重复构建

提示：构建目录可以存在多个，分别对应不同 MACHINE 或 DISTRO。共享 sstate-cache 和 downloads 目录能显著减少重复下载与编译。

四、镜像生成与 SDK 生成

镜像生成的核心任务是 do_rootfs。它根据镜像配方中的 IMAGE_INSTALL 列表，从包仓库中安装软件包，生成根文件系统。随后 do_image 系列任务将其转换为具体格式。例如 core-image-minimal 默认生成 .tar.bz2 和 .ext4，若启用 wic 还会生成可直接烧录的 .wic 文件。

SDK 生成则通过 populate_sdk 任务完成。它从当前构建中提取交叉编译器、目标 sysroot、库和头文件，并打包成自解压安装脚本。安装后，开发者可在宿主机上使用 source environment-setup-* 激活交叉编译环境，直接编译应用程序，而无需重新构建整个 Yocto 系统。

# SDK 安装与使用
./poky-glibc-x86_64-core-image-minimal-cortexa7t2hf-neon-vfpv4-toolchain-4.0.sh
source /opt/poky/4.0/environment-setup-cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi
$CC hello.c -o hello

五、案例与误区复盘

案例场景：某团队需要为 ARM 开发板构建带 Qt 的镜像并导出 SDK。他们在 local.conf 中设置 MACHINE = "qemuarm"，在镜像配方中加入 IMAGE_INSTALL:append = " qtbase qtdeclarative"，然后执行 bitbake core-image-weston -c populate_sdk。构建完成后，在 tmp/deploy/sdk/ 下得到工具链安装包，在 tmp/deploy/images/qemuarm/ 下得到镜像。

常见误区：

  • 直接修改 tmp/work 下的源码：这些目录会被任务清理或覆盖，正确做法是修改配方或使用 devtool modify。
  • 忽略依赖解析报错：“Nothing PROVIDES”通常意味着层未加入或配方名拼写错误，应检查 bblayers.conf 和 PROVIDES。
  • 把 SDK 当成完整系统：SDK 只提供交叉编译能力，不包含目标设备的完整运行时，仍需配合镜像使用。
  • 不清理 sstate 导致磁盘爆满：长期构建应定期清理 tmp/work，但保留 sstate-cache 以加速后续构建。

注意：修改 local.conf 中的 MACHINE 后，建议使用独立的构建目录，避免不同架构的中间产物相互污染。

Yocto 构建流程：从元数据到镜像与 SDK 元数据 Metadata 配方 .bb / .bbappend 配置 local.conf / bblayers 类 .bbclass BitBake 解析 扫描层与配方 计算 DEPENDS / RDEPENDS 生成任务依赖图 任务执行 Task fetch → unpack → patch configure → compile install → package 构建目录 tmp/work tmp/deploy sstate-cache 中间产物：包（Packages）与 sysroot .ipk / .rpm / .deb · 目标库与头文件 镜像生成 do_rootfs / do_image IMAGE_INSTALL 组装根文件系统 输出 .wic / .ext4 / .tar.bz2 tmp/deploy/images/<machine>/ SDK 生成 populate_sdk 提取交叉工具链与目标 sysroot 打包为自解压安装脚本 tmp/deploy/sdk/ 依赖解析决定任务顺序 · 构建目录承载中间产物 · 镜像面向设备 · SDK 面向开发者

总结来看，Yocto 构建流程的本质是“元数据驱动、任务编排、依赖约束、目录隔离、产物分层”。掌握配方与任务的关系、依赖解析的规则、构建目录的结构，以及镜像与 SDK 的生成路径，就能在交叉开发环境中稳定地复现构建、定位问题并交付可用的系统与工具链。

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