2、Yocto核心概念：Recipe、Layer、Machine、Distro、BitBake任务系统

好，咱们进入正题。Yocto 这东西，刚接触时容易懵——概念太多，Recipe、Layer、Machine、Distro…… 说实话，我当年第一次看文档，差点被这些术语劝退。但后来我发现，只要抓住几个核心概念，整个系统就清晰了。

说白了，Yocto 就是一个「搭积木」的系统。你定义好硬件平台（Machine）、软件特性（Distro），然后 BitBake 根据 Recipe 去下载、编译、打包，最后生成一个完整的 Linux 系统镜像。Layer 就是把这些积木分门别类放好的抽屉。

咱们一个一个来拆解。

2.1 Recipe（配方）—— 构建的最小单元

Recipe 是 Yocto 里最基本的构建单元。它告诉 BitBake：你要从哪里下载源码、怎么打补丁、怎么配置编译、安装到哪个目录。

一个典型的 Recipe 文件长这样：

SUMMARY = "Hello World 示例程序"
DESCRIPTION = "一个简单的 Yocto Recipe 示例"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

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}
}

嗯，这里要注意几个关键变量：

  • SRC_URI：源码位置。可以是本地文件、Git 仓库、tarball 链接。
  • S：源码解压后的目录。默认是 ${WORKDIR}/${PN}-${PV}，但很多人会踩坑。
  • do_compile、do_install：这是 BitBake 的任务函数，后面会细说。
我的经验： 写 Recipe 时，最容易犯的错就是 S 变量没设对。我曾经有个项目，源码解压后目录名和 Recipe 名不一致，BitBake 死活找不到源码。排查了半天，最后发现 S 指向了错误路径。所以，建议你在 do_unpack 后加个 debug 打印，确认一下目录结构。

2.2 Layer（层）—— 模块化组织

Layer 是 Yocto 用来组织 Recipe、配置、补丁的「抽屉」。每个 Layer 负责一类功能：

  • meta：核心层，包含 OE 基础 Recipe
  • meta-poky：Poky 参考发行版配置
  • meta-yocto-bsp：参考 BSP（板级支持包）
  • meta-raspberrypi：树莓派相关 Recipe
  • meta-qt5：Qt5 相关 Recipe

Layer 的结构有约定：

meta-mylayer/
├── conf/
│   ├── layer.conf          # Layer 配置文件
│   └── machine/            # 机器配置
├── recipes-example/
│   └── hello/
│       ├── hello_1.0.bb    # Recipe 文件
│       └── files/
│           └── hello.c     # 源码文件
├── recipes-core/
│   └── images/
│       └── my-image.bb     # 镜像 Recipe
└── COPYING.MIT

为什么需要 Layer？说白了就是为了复用。你想想看，如果所有 Recipe 都塞在一个目录里，那维护起来就是灾难。Layer 让你可以把硬件相关、软件相关、自定义修改分开管理。

避坑指南： Layer 的优先级（BBFILE_PRIORITY）很重要。我曾经遇到过两个 Layer 都定义了同一个 Recipe，结果 BitBake 用了优先级高的那个，导致编译出来的东西不是我想要的。所以，自定义 Layer 时，记得把优先级设高一点（比如 6 或 7），确保你的修改能覆盖上游。

2.3 Machine（机器）—— 硬件描述

Machine 定义了目标硬件平台。它告诉 Yocto：CPU 架构是什么、内核用什么、U-Boot 怎么配置、串口是哪个。

一个 Machine 配置文件通常放在 conf/machine/ 目录下：

# conf/machine/myboard.conf

require conf/machine/include/arm/armv7a/tune-cortexa7.inc

MACHINEOVERRIDES = "myboard"

PREFERRED_PROVIDER_virtual/kernel = "linux-myboard"

SERIAL_CONSOLES = "115200;ttyS0"

MACHINE_FEATURES = "apm usbgadget usbhost vfat alsa"

IMAGE_FSTYPES += "tar.bz2 ext4"

这里有几个关键点：

  • require：引入 CPU 架构的 tune 文件，定义编译优化参数
  • PREFERRED_PROVIDER：指定使用哪个内核 Recipe
  • SERIAL_CONSOLES：调试串口配置，这个设错了，你连控制台都看不到
  • IMAGE_FSTYPES：生成镜像的格式，比如 ext4、tar.bz2、wic
注意： Machine 名称不能有空格或特殊字符。我见过有人把板子型号写成 "My Board v2.0"，结果 BitBake 解析时直接报错。建议用全小写加连字符，比如 "myboard-v2"。

2.4 Distro（发行版）—— 软件特性定义

Distro 定义了你的 Linux 发行版的「性格」。它决定了：用什么 C 库（glibc 还是 musl）、是否开启 systemd、默认的 init 系统是什么、包管理用哪个。

一个典型的 Distro 配置文件：

# conf/distro/mydistro.conf

DISTRO_NAME = "MyDistro"
DISTRO_VERSION = "1.0"
DISTRO_CODENAME = "mycode"

MAINTAINER = "your-email@example.com"

TARGET_VENDOR = "-mydistro"

PREFERRED_VERSION_linux-libc-headers = "5.10"

DISTRO_FEATURES = "systemd wifi bluetooth usbhost"

VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"

我个人习惯把 Distro 配置和 Machine 配置分开。Machine 管硬件，Distro 管软件。这样换硬件平台时，只需要改 Machine，Distro 基本不动。

举个例子：你有一个产品线，既有 ARM 版又有 x86 版。只要 Distro 配置一样，两个平台的软件特性就完全一致。这就是 Yocto 多架构支持的精髓。

2.5 BitBake 任务系统

BitBake 是 Yocto 的构建引擎。它把 Recipe 里的 do_xxx 函数组织成一个任务依赖图，然后按顺序执行。

标准的任务流程是这样的：

do_fetch      → 下载源码
do_unpack     → 解压源码
do_patch      → 打补丁
do_configure  → 配置（比如 ./configure）
do_compile    → 编译
do_install    → 安装到临时目录
do_package    → 打包成 ipk/deb/rpm
do_populate_sysroot → 安装到 sysroot（供其他 Recipe 依赖）
do_build      → 最终构建完成

每个任务都可以被重写或扩展。比如你想在编译前加个自定义步骤：

addtask my_custom_step before do_compile after do_patch

do_my_custom_step() {
    echo "我在编译前干点私活..."
    # 比如修改源码中的版本号
    sed -i 's/VERSION="1.0"/VERSION="2.0"/' ${S}/version.h
}

BitBake 的依赖解析很智能。你运行 bitbake core-image-minimal，它会自动分析所有依赖，然后并行执行不冲突的任务。我见过一个大型项目，2000 多个 Recipe，BitBake 能自动调度出最优的并行方案。

调试技巧： 当构建失败时，用 bitbake -c cleansstate <recipe> 清理该 Recipe 的缓存，然后重新编译。如果还不行，用 bitbake -c devshell <recipe> 进入一个包含所有环境变量的 shell，手动执行编译命令，排查问题。这个 devshell 是我最常用的调试手段，没有之一。

2.6 它们如何协同工作？

咱们用一个实际场景串起来：

  1. 你执行 bitbake core-image-minimal
  2. BitBake 读取 Machine 配置，知道目标平台是 ARM Cortex-A7
  3. 读取 Distro 配置，知道要用 systemd、glibc
  4. 遍历所有 Layer，找到 core-image-minimal 这个镜像 Recipe
  5. 镜像 Recipe 依赖一堆 Recipe（比如 busybox、udev、kernel）
  6. BitBake 为每个 Recipe 执行任务链：fetch → unpack → patch → configure → compile → install → package
  7. 最终生成一个完整的根文件系统镜像

整个过程，你只需要定义好 Machine 和 Distro，剩下的 BitBake 自动搞定。这就是 Yocto 的威力。

总结一下：
  • Recipe：告诉 BitBake 怎么构建一个软件包
  • Layer：把 Recipe 和配置分门别类
  • Machine：描述硬件平台
  • Distro：定义软件发行版特性
  • BitBake 任务系统：调度执行所有构建步骤
这五个概念，就是 Yocto 的「五根柱子」。理解了它们，你就掌握了 Yocto 的骨架。

下一章，咱们会动手搭建一个实际的多架构项目。到时候，这些概念会一个个活起来。

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