4. BitBake深度解析：任务执行、变量作用域与依赖机制
BitBake是Yocto的心脏。说白了，它就是个专为嵌入式构建设计的任务调度器。我见过不少新手把BitBake当成普通Makefile来用，结果被它的变量作用域和依赖解析搞得焦头烂额。这一章，咱们就把BitBake的底裤扒干净。
4.1 BitBake任务执行模型
BitBake的任务执行不是简单的顺序执行。它维护了一个任务依赖图（DAG），每个任务都有前置条件。举个例子，do_compile必须在do_configure完成后才能跑。
核心概念：BitBake的任务状态机包含四个状态：未就绪 → 就绪 → 运行中 → 完成/失败。只有所有依赖任务都进入完成状态，当前任务才能从未就绪切换到就绪。
任务执行流程大致如下：
- 解析所有.bb和.bbclass文件，构建任务依赖图
- 计算每个任务的校验和（基于输入变量、文件内容等）
- 检查缓存（sstate-cache），如果校验和匹配则跳过
- 按拓扑排序执行任务，并行度由BB_NUMBER_THREADS控制
我在项目中遇到过一个问题：两个recipe都修改了同一个系统配置文件，结果构建时出现竞争条件。后来我强制给其中一个recipe加了do_install[depends]，才解决了这个隐式依赖。
4.2 .bb与.bbclass文件
.bb文件是recipe，描述怎么构建一个软件包。.bbclass是类文件，封装可复用的构建逻辑。我习惯把通用逻辑（比如autotools、cmake的构建流程）写在.bbclass里，然后在.bb文件中通过inherit关键字引用。
个人习惯：我通常把.bbclass放在meta-xxx/classes/目录下，.bb文件放在meta-xxx/recipes-xxx/目录下。这样结构清晰，团队协作时也容易定位问题。
看个实际例子：
# meta-myboard/classes/my-custom.bbclass
MY_VAR ?= "default_value"
do_my_task() {
echo "Running my custom task with ${MY_VAR}"
}
addtask my_task after do_compile before do_install
# meta-myboard/recipes-example/hello/hello_1.0.bb
inherit my-custom
MY_VAR = "overridden_value"
do_compile() {
echo "Compiling hello world"
}
这里有个关键点：inherit是在解析阶段执行的，所以.bbclass中的变量和函数会被.bb文件中的定义覆盖。我曾经踩过这个坑——在.bbclass里定义了一个函数，然后在.bb文件里用addtask改了依赖顺序，结果发现.bbclass里的函数根本没执行。后来才意识到，addtask必须在inherit之后才能正确覆盖。
4.3 变量作用域与覆盖
BitBake的变量作用域是层级式的。从全局到局部，优先级依次递增：
| 层级 | 配置文件 | 优先级 |
|---|---|---|
| 全局默认 | bitbake.conf | 最低 |
| 发行版配置 | distro.conf | 中 |
| 机器配置 | machine.conf | 高 |
| 本地配置 | local.conf | 更高 |
| Recipe层 | .bb文件 | 最高 |
变量覆盖操作符有四种：
=：直接赋值，覆盖之前的值?=：弱赋值，仅当变量未定义时生效??=：更弱赋值，在所有?=之后才生效+=/=+：追加/前置追加，带空格.=/=.：追加/前置追加，不带空格
避坑指南：我曾经在local.conf里用PREFERRED_VERSION_xxx = "1.0"，结果发现不管用。排查了半天，发现是某个.bbappend文件里用了PREFERRED_VERSION_xxx = "2.0"，直接覆盖了local.conf的设置。记住：.bb文件的优先级高于local.conf！
变量覆盖的解析顺序是这样的：
- 先解析所有.bbclass文件
- 再解析.bb文件
- 最后解析.bbappend文件
- 同层级的文件按文件名排序，后解析的覆盖先解析的
4.4 依赖解析机制
BitBake的依赖解析分为两种：构建时依赖（DEPENDS）和运行时依赖（RDEPENDS）。
DEPENDS：告诉BitBake，在构建当前包之前，必须先构建好这些依赖包。这些依赖包的头文件、库文件会被安装到sysroot中。
RDEPENDS：告诉BitBake，当前包安装到目标系统后，需要哪些运行时依赖包。这些包会被打包进镜像。
依赖解析的流程：
- BitBake读取所有recipe的DEPENDS和RDEPENDS
- 构建完整的依赖图（DAG）
- 检测循环依赖（如果有，报错并停止）
- 按拓扑排序确定构建顺序
实战经验：我在做一个多媒体播放器项目时，发现依赖链特别长。BitBake解析了300多个recipe，构建时间超过2小时。后来我用了bitbake -g生成依赖图，发现有个不必要的循环依赖——两个库互相依赖对方的测试工具。去掉这个循环后，构建时间缩短了40%。
依赖解析的常见问题：
| 问题 | 现象 | 解决方案 |
|---|---|---|
| 循环依赖 | BitBake报错：Dependency loop detected | 检查DEPENDS和RDEPENDS，移除不必要的依赖 |
| 缺失依赖 | 构建失败，找不到头文件或库 | 在DEPENDS中添加缺失的包 |
| 版本冲突 | 多个版本同时存在，构建不确定 | 使用PREFERRED_VERSION指定版本 |
| 隐式依赖 | 构建成功但运行时崩溃 | 在RDEPENDS中显式声明运行时依赖 |
嗯，这里要注意：BitBake的依赖解析是静态的，它不会检查你的代码里实际用了哪些库。所以，如果你在代码里链接了libfoo，但DEPENDS里没写libfoo，构建可能成功（因为libfoo可能已经被其他包拉进来了），但换一个构建环境就可能失败。我建议每次提交代码前，都用bitbake -s检查一下依赖树，确保没有遗漏。
最后说一句：依赖解析是Yocto构建的骨架。骨架搭不好，后面加再多肌肉（功能）也白搭。花时间理解依赖机制，绝对值得。