4、BitBake入门：BitBake是什么、BitBake的工作流程、.bb和.bbclass文件、任务(task)的概念、依赖关系解析。
好，咱们进入第四讲。前面几章我们把Yocto的宏观架构和开发环境搭建讲完了。从这一章开始，我们要深入一个核心工具——BitBake。
说实话，我刚接触Yocto那会儿，最头疼的就是BitBake。它不像Makefile那么直观，也不像CMake那样有图形界面。它有一套自己的哲学。但一旦你理解了它的设计思路，你会发现它其实非常优雅。
BitBake是什么？
BitBake，说白了，就是一个任务执行引擎。它专门为嵌入式Linux的构建而设计。
你可以把它想象成一个超级智能的“包工头”。你告诉它：“我要一个能跑在ARM板子上的Linux系统。” 它就会自动去拉取源码、打补丁、配置、编译、打包，最后生成一个完整的镜像。
它和Make最大的区别是什么？
Make是基于文件的依赖。如果某个文件没变，它就不重新编译。而BitBake是基于任务的依赖。它不光看文件有没有变，还看任务的输入、输出、甚至环境变量有没有变。粒度更细，也更可靠。
核心概念：BitBake是一个元构建系统。它不直接调用gcc或ld，而是通过解析.bb和.bbclass文件，生成一个任务依赖图，然后按顺序执行这些任务。
BitBake的工作流程
BitBake的工作流程，我习惯把它分成三个阶段：
- 解析阶段：读取所有配置文件（local.conf、bblayers.conf等），解析所有.bb和.bbclass文件，构建全局数据字典。
- 依赖计算阶段：根据解析结果，构建任务依赖图。确定哪些任务需要先执行，哪些可以并行。
- 执行阶段：按照依赖图，依次或并行执行任务。每个任务都在独立的进程中运行，互不干扰。
嗯，这里要注意一点。BitBake的解析是惰性的。它不会一开始就把所有.bb文件都解析完。而是按需解析。你只编译某个包，它只解析那个包相关的文件。这大大加快了启动速度。
我在项目中遇到过一个问题：修改了一个全局的.bbclass文件，结果发现某些包没有重新编译。后来才意识到，BitBake的缓存机制太强了。它认为那个包的输入没变，所以跳过了。解决办法是执行 bitbake -c cleanall <包名> 强制清除缓存。
.bb和.bbclass文件
这两个文件是BitBake的灵魂。
- .bb文件：配方文件。描述了一个软件包如何被构建。比如
openssl_1.1.1.bb就告诉BitBake如何下载、配置、编译和安装OpenSSL。 - .bbclass文件：类文件。相当于一个函数库或模板。多个.bb文件可以继承同一个.bbclass，共享通用的构建逻辑。
举个例子，你写一个.bb文件，通常第一行就是：
inherit autotools这行代码告诉BitBake：“我这个包使用autotools构建系统，请帮我处理configure、make、make install这些步骤。” 而 autotools.bbclass 里已经把这些逻辑写好了。
我个人习惯把通用的、可复用的逻辑都放到.bbclass里。比如自定义的打包规则、测试框架、代码风格检查等。这样.bb文件就非常干净，只包含包特有的信息。
小技巧：如果你发现多个.bb文件里有重复的代码，那就是提取到.bbclass的好时机。我曾经把十几个Wi-Fi驱动包的公共部分抽成一个 wifi-driver.bbclass，维护成本瞬间降低。
任务(task)的概念
在BitBake的世界里，一切都是任务。
一个典型的构建流程，包含以下任务：
| 任务名 | 说明 |
|---|---|
do_fetch |
从网络或本地获取源码 |
do_unpack |
解压源码包 |
do_patch |
应用补丁 |
do_configure |
配置（如运行./configure） |
do_compile |
编译（如运行make） |
do_install |
安装到临时目录 |
do_package |
打包成IPK/RPM/DEB |
do_build |
默认任务，执行上述所有任务 |
你可以通过 bitbake -c <任务名> <包名> 来单独执行某个任务。比如：
bitbake -c compile openssl这只会编译OpenSSL，不会重新配置或打包。调试时非常有用。
你想想看，这种设计有什么好处？
假设你只改了某个包的配置文件，你不需要重新下载源码、重新打补丁。只需要从 do_configure 开始执行就行。BitBake会自动跳过那些输入没变的任务。
避坑指南：我曾经犯过一个错误，直接执行 bitbake -c compile 后发现编译失败，但明明源码没改。后来排查了半天，发现是 do_configure 生成的Makefile被我不小心改了。所以，如果遇到莫名其妙的编译错误，先执行 bitbake -c clean 再重试。
依赖关系解析
这是BitBake最强大的地方。它能把整个系统的依赖关系理得清清楚楚。
依赖关系分两种：
- 构建时依赖：用
DEPENDS变量声明。比如你的程序需要libfoo，那么DEPENDS += "libfoo"。BitBake会确保libfoo先被构建好。 - 运行时依赖：用
RDEPENDS变量声明。比如你的程序运行时需要libfoo.so，那么RDEPENDS_${PN} += "libfoo"。这会影响最终镜像的打包。
举个例子：
# myapp.bb
DESCRIPTION = "My Awesome Application"
DEPENDS = "libfoo libbar"
RDEPENDS_${PN} = "libfoo libbar bash"这段代码告诉BitBake：
- 构建myapp之前，必须先构建libfoo和libbar。
- myapp安装到目标板后，必须同时安装libfoo、libbar和bash。
BitBake会递归解析这些依赖。如果libfoo又依赖libbaz，BitBake会自动把libbaz也加进来。你不需要手动管理传递依赖。
嗯，这里有个坑。有时候你改了某个底层库，比如glibc，你以为所有包都会重新编译。但BitBake的依赖计算是基于签名的。如果glibc的接口没变，只是内部实现变了，BitBake可能认为依赖它的包不需要重新编译。这时候，你需要用 bitbake -S none <包名> 来查看签名变化，或者干脆执行一次全量重编。
我个人习惯在修改了关键库后，执行：
bitbake -c cleanall world
bitbake core-image-minimal虽然慢，但最保险。尤其是在项目交付前，我会做一次干净的完整构建，确保没有隐藏的依赖问题。
好了，这一章的内容就到这里。BitBake的入门知识，说白了就是理解它的任务模型和依赖解析。下一章，我们会深入.bb文件的编写，教你如何从零开始写一个自己的配方。