bitbake 使用指南

bitbake 使用指南

如果说 Linux 系统镜像是你想吃的一桌饭菜，那么 Yocto 就是一家餐厅，Poky 就是厨房，BitBake 就是厨师。那么，如果我们想定制自己的 Linux，我们应该学会怎么用好 BitBake，或者说把我们的意图告诉 BitBake。总而言之，如果你想定制 Linux 系统的愿望跟你想吃一桌好吃的饭菜一样强烈的话（或者更强烈），你应该好好了解了解 BitBake。

1. 认识 BitBake

OE BitBake 是一个软件组建自动化工具程序，像所有的 build 工具一样（比如 make，ant，jam）控制如何去构建系统并且解决构建依赖。但是又区别于功能单一的工程管理工具(比如make)，bitbake不是基于把依赖写死了的makefile，而是收集和管理大量之间没有依赖关系的描述文件(这里我们称为包的配方)，然后自动按照正确的顺序进行构建。oe代表OpenEmbedded，而openembedded是一些用来交叉编译，安装和打包的metadata(元数据)。

OpenEmbedded 是一些脚本（shell 和 python 脚本）和数据构成的自动构建系统。脚本实现构建过程，包括-（fetch）、解包（unpack）、打补丁（patch）、配置（configure）、编译（compile）、安装（install）、打包（package）、staging、做安装包（package_write_ipk）、构建文件系统等。

OE 编译顺序：

do_setscenedo_fetchdo_unpackdo_pathdo_configuredo_qa_configuredo_compiledo_stagedo_installdo_packagedo_populate_stagingdo_package_write_debdo_package_writedo_distribute_sourcesdo_qa_stagingdo_builddo_rebuild

注意：do_compile 这些函数都是在 OpenEmbedded 的 classes 中定义的，而 bitbake 中并没有对这些进行定义。这说明，bitbake 只是 OE 更底层的一个工具，也就是说，OE 是基于 bitbake 架构来完成的。

数据主要提供两个方面的信息：

特定软件包的构建信息怎样获取源代码和补丁？怎样构建，用 Makefile 还是 Autotool？需要向目标编译环境输出哪些文件？需要安装哪些文件？每个软件包都需要描述文件。事实上，每个软件包的不同版本都有一个描述文件。软件包之间的依赖关系构建软件包 A 需要先构建什么主机平台工具，什么目标平台工具？软件包A在编译时依赖哪些软件包？软件包A在运行时依赖哪些软件包？一个目标应包含那些软件包，这些依赖关系把几百个软件包联系在一起，构成了一个完整的系统。

基于bitbake，OE可以满足以下所有要求：

解决交叉编译解决包之间的依赖关系必须支持包的管理（tar,rpm,ipk）必须支持将包作成镜像必须支持高度的可定制性，以满足不同的机器，主机发行版和架构需求编写元数据必须是容易的，并且可重用性要好

OE 的主要功能是为各种工程项目的需要编译源码。不管是什么工程，以下任务都是需要做的：

-源码包，还有其他的系统支持文件（比如初始化脚本）解压源码包，然后打上需要的补丁如果需要，对软件包进行配置（比如运行 configure 脚本）编译所有的东西把编译好的文件打成各种格式的包，然后准备安装

其实这些并没有什么不寻常的，困难的是：

交叉编译：交叉编译是困难的，大部分软件包根本不支持交叉编译，OE 里包含的都是支持交叉编译的。目标系统和主机是不同的：这意味着你不能编译一个程序就直接运行它，因为它要运行在目标板上。很多软件包在编译的时候会编译并且运行一些帮助或者测试程序，这在交叉编译时会导致失败。工具链总是很难编译的，交叉工具链更是如此。通常情况下，你可能会选择去-一个别人做好的，但是使用 OE 你就不需要如此。在 OE 里整个工具链在编译系统的时候都会被创建，OE 的这种方式或许在开始的时候会带来一些困难和不便。但是如果你需要打上补丁或者对工具链做些调整就会很容易。

当然，除此之外，OE 还有很多的功能，其中包括：

同时支持 glibc 和 uclibc只使用 OE 一个工具你就可以为多种目标机器构建系统自动编译一切构建时和编译时依赖的包直接创建各种可以在目标机器上直接运行的镜像（包括 jffs2、ext2.gz、squashfs 等等）支持各种打包格式自动构建交叉工具链支持构建“本地包”（本地包指为了完成编译而给主机编译的包，最终不会用到目标板上）

2. 文件系统里的 OpenEmbedded

OE 环境中最重要的目录有3个：

放工具的 bitbake 目录放元数据的目录执行构建的 build 目录

2.1 bitbake 目录

这个目录里的是我们的厨师（或理解为烹饪工具）——bitbake，我们使用它，但通常不需要访问、修改它。

2.2 元数据目录

在 poky 中元数据目录是 meta，Openmoko 中元数据目录是 openembedded。在元数据目录中，有3个目录里是真正的元数据，它们是：classes、conf 和 packages。

2.2.1 packages 目录

所有的配方（recipes）文件（后缀为 .bb）都放在 package 目录，每个相对独立的软件包或构建任务在 package 目录下都有自己的子目录。在一个子目录中可以有多个配方（recipes）文件，它们可能是同一个软件包的不同版本，也可能描述了基于同一个软件包的不同构建目标。

有的配方（recipes）简单，有的配方（recipes）复杂。简单的配方仅描述一个软件包的构建，最复杂的是要求构建文件系统的配方，这个配方文件本身并不长，甚至还很短，但它通过依赖关系将几百个甚至几千个其它配方文件卷入了构建过程。packages 目录的 images 子目录下就是这些要求构建文件系统的配方（recipes）。

2.2.2 classes 目录

这个目录放的是配方（recipes）的类文件（后缀为 .bbclass）。类文件包含了一些 bitbake 任务的定义，例如怎么配置、怎么安装。配方文件继承类文件，也就继承了这些任务的定义。例如：我们如果增加一个使用 autotool 的软件包，只要在配方文件中继承 autotools.bbclass：

inherit autotools

bitbake 就知道怎样使用 autotool 工具配置、编译、安装了。所有的配方文件都自动继承了 base.bbclass。base.bbclass 提供了大部分 bitbake 任务的默认实现。

一个配方文件可以继承多个类文件。以后的文章会介绍 bitbake 的任务，届时会更详细地讨论 bitbake 的继承。目前，我们只要知道继承类文件是一种构建过程的复用方式就可以了。

2.2.3 conf 目录

conf 目录包含编译系统的配置文件（后缀为 .conf）。bitbake 在启动时会执行 bitbake.conf，bitbake.conf 会装载用户提供的 local.conf，然后根据用户在 local.conf 中定义的硬件平台（MACHINE）和发布目标（DISTRO）装载 machine 子目录和 distro 子目录的配置文件。machine 子目录里是与硬件平台相关的配置文件，distro 子目录里是与发布目标相关的配置文件。配置文件负责设置 bitbake 内部使用的环境变量，这些变量会影响整个构建过程。

2.3 build 目录

build 是我们烹饪嵌入式系统的地方（可以想象成餐馆的大厨房），整个构建过程就是在 build 目录的 tmp 子目录完成的。build 目录的 conf 子目录里是用户的配置文件 local.conf。

tmp 目录有7个子目录：cache、cross、rootfs、staging、work、deploy 和 stamps 目录。其中 cache 是 bitbake 内部使用的缓存目录。cross 是构建过程中产生的交叉编译器（所谓交叉编译器就是在主机平台运行，用于编译目标平台代码的编译器）。rootfs 是制作文件系统映像前临时建立的根文件系统。我们的工作中通常不需要访问这3个目录，我们访问比较多的是其它4个目录：staging、work、deploy 和 stamps 目录。

2.3.1 staging 目录

软件包 B 在构建时可能依赖软件包 A 提供的头文件、库文件，也可能要使用软件包 C 生成的工具。staging 目录就是放这些输出文件的地方。

2.3.2 work 目录

所有软件包的解包、打补丁、配置、编译、安装等工作都是在 work 目录进行的。所以 work 目录包含了整个嵌入式系统的完整源代码。

work 目录下按照硬件平台、发行人、目标平台的不同又分了几个目录。所有软件包都被放在对应的子目录中，每个软件包都有一个独立的目录。因为软件包总是根据一个配方文件构建的，所以软件包所在的目录就是对应配方文件的工作目录。在讨论 bitbake 和配方文件时我们还会回来，更仔细地观察配方文件的工作。

2.3.3 deploy 目录

这是保存输出成果的目录。其中 images 目录保存构建成功后产生的文件系统映像、内核映像，ipk 目录保存每个软件包的安装包。我们在修改、构建软件包后，可以在目标平台手工安装 ipk 目录下的对应安装包，确认没有问题后，再制作文件系统映像。

2.3.4 stamps 目录

和 work 目录类似，stamp 目录也按照硬件平台、发行人、目标平台的不同又分了几个子目录。软件包在完成每个 bitbake 任务后都会在对应子目录里 touch 一个对应任务的时间戳，有时我们会手工删除某个软件包的时间戳，强制 bitbake 重新构建这个软件包。

2.3.5 sources 目录

OE 环境的 sources 目录是一个储藏间，用来放从网上-的源代码包。fetch 任务负责-代码，放到 sources 目录。

3. BitBake 命令

3.1 查看 bitbake 命令

$ bitbake -hUsage: bitbake [options] [recipename/target recipe:do_task ...] Executes the specified task (default is 'build') for a given set of target recipes (.bb files). It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH which will provide the layer, BBFILES and other configuration information.Options: --version show program's version number and exit -h, --help show this help message and exit -b BUILDFILE, --buildfile=BUILDFILE Execute tasks from a specific .bb recipe directly. WARNING: Does not handle any dependencies from other recipes. -k, --continue Continue as much as possible after an error. While the target that failed and anything depending on it cannot be built, as much as possible will be built before stopping. -a, --tryaltconfigs Continue with builds by trying to use alternative providers where possible. -f, --force Force the specified targets/task to run (invalidating any existing stamp file). -c CMD, --cmd=CMD Specify the task to execute. The exact options available depend on the metadata. Some examples might be 'compile' or 'populate_sysroot' or 'listtasks' may give a list of the tasks available. -C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMP Invalidate the stamp for the specified task such as 'compile' and then run the default task for the specified target(s). -r PREFILE, --read=PREFILE Read the specified file before bitbake.conf. -R POSTFILE, --postread=POSTFILE Read the specified file after bitbake.conf. -v, --verbose Output more log message data to the terminal. -D, --debug Increase the debug level. You can specify this more than once. -n, --dry-run Don't execute, just go through the motions. -S SIGNATURE_HANDLER, --dump-signatures=SIGNATURE_HANDLER Dump out the signature construction information, with no task execution. The SIGNATURE_HANDLER parameter is passed to the handler. Two common values are none and printdiff but the handler may define more/less. none means only dump the signature, printdiff means compare the dumped signature with the cached one. -p, --parse-only Quit after parsing the BB recipes. -s, --show-versions Show current and preferred versions of all recipes. -e, --environment Show the global or per-recipe environment complete with information about where variables were set/changed. -g, --graphviz Save dependency tree information for the specified targets in the dot syntax. -I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED Assume these dependencies don't exist and are already provided (equivalent to ASSUME_PROVIDED). Useful to make dependency graphs more appealing -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS Show debug logging for the specified logging domains -P, --profile Profile the command and save reports. -u UI, --ui=UI The user interface to use (depexp, goggle, knotty or ncurses - default knotty). -t SERVERTYPE, --servertype=SERVERTYPE Choose which server type to use (process or xmlrpc - default process). --token=XMLRPCTOKEN Specify the connection token to be used when connecting to a remote server. --revisions-changed Set the exit code depending on whether upstream floating revisions have changed or not. --server-only Run bitbake without a UI, only starting a server (cooker) process. -B BIND, --bind=BIND The name/address for the bitbake server to bind to. --no-setscene Do not run any setscene tasks. sstate will be ignored and everything needed, built. --setscene-only Only run setscene tasks, don't run any real tasks. --remote-server=REMOTE_SERVER Connect to the specified server. -m, --kill-server Terminate the remote server. --observe-only Connect to a server as an observing-only client. --status-only Check the status of the remote bitbake server. -w WRITEEVENTLOG, --write-log=WRITEEVENTLOG Writes the event log of the build to a bitbake event json file. Use '' (empty string)

3.2 bitbake 常用命令

3.3 使用举例

单独编译 kernel、模块、设备树

MYS-6ULX-IOT 开发板对应的 kernel 是 linux-mys6ulx：

$ bitbake -c menuconfig -f -v linux-mys6ulx$ bitbake -c compile -f -v linux-mys6ulx$ bitbake -c compile_kernelmodules -f -v linux-mys6ulx$ bitbake -c deploy -f -v linux-mys6ulx

也有一些资料用 virtual/kernel 来指定 kernel，命令变成这样了：

$ bitbake -c menuconfig virtual/kernel$ bitbake -c compile -f -v virtual/kernel$ bitbake -c compile_kernelmodules -f -v virtual/kernel$ bitbake -c deploy -f -v virtual/kernel

通过 sources/meta-myir-imx6ulx/conf/machine/include/mys6ulx-base.inc 和 sources/meta-myir-imx6ulx/conf/distro/include/myir-imx-preferred-evn.inc 文件，我们可以看出一些端倪：

MACHINE_ARCH_FILTER = "virtual/kernel"# Handle default kernelIMX_DEFAULT_KERNEL = "linux-mys6ulx"IMX_DEFAULT_KERNEL_mx6ul = "linux-mys6ulx"IMX_DEFAULT_KERNEL_mx6ull = "linux-mys6ulx"PREFERRED_PROVIDER_virtual/kernel ??= "${IMX_DEFAULT_KERNEL}"

单独编译 u-boot

$ bitbake -c compile -f -v u-boot-mys6ulx$ bitbake -c deploy -f -v u-boot-mys6ulx

编译文件系统

$ bitbake core-image-minimal$ bitbake core-image-base$ bitbake fsl-image-gui$ bitbake fsl-image-qt5$ bitbake fsl-image-multimedia

清除编译结果

$ bitbake -c clean -v linux-mys6ulx

清除还包括 clean、cleanall、cleanstate

参考

​​Project 上的 BitBake 用户手册：​​​https://yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html​​

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。