BitBake概述

最新推荐文章于 2023-01-30 17:29:46 发布

whcz

最新推荐文章于 2023-01-30 17:29:46 发布

阅读量3.7k

点赞数

分类专栏： YOCTO

本文链接：https://blog.csdn.net/u013921164/article/details/110958428

版权

YOCTO 专栏收录该内容

14 篇文章 21 订阅

订阅专栏

1概述

欢迎使用《 BitBake用户手册》。本手册提供有关BitBake工具的信息。有关使用BitBake的系统（例如OpenEmbedded和Yocto Project）的信息尝试尽可能地独立。在某些情况下，本手册中使用了构建系统上下文中的场景或示例来帮助理解。对于这些情况，该手册明确说明了上下文。

1.1引言

从根本上讲，BitBake是一个通用的任务执行引擎，它使Shell和Python任务可以在复杂的任务间依赖关系约束内有效地并行运行。BitBake的主要用户之一OpenEmbedded以此内核为基础，并使用面向任务的方法构建嵌入式Linux软件堆栈。

从概念上讲，BitBake在某些方面类似于GNU Make，但有很大的区别：

BitBake根据提供的构成任务的元数据执行任务。元数据存储在配方（.bb）和相关配方“追加”（.bbappend）文件，配置（.conf）和基础包含（.inc）文件以及类（.bbclass）文件中。元数据向BitBake提供有关要运行哪些任务以及这些任务之间的依赖关系的说明。
BitBake包含一个提取程序库，用于从各个地方（例如本地文件，源代码控制系统或网站）获取源代码。
每个要构建的单元的指令（例如，一个软件）被称为“配方”文件，其中包含有关该单元的所有信息（依赖项，源文件位置，校验和，描述等）。
BitBake包含客户端/服务器抽象，可以从命令行使用，也可以通过XML-RPC用作服务，并且具有多个不同的用户界面。

1.2历史和目标

BitBake最初是OpenEmbedded项目的一部分。它的灵感来自Gentoo Linux发行版使用的Portage软件包管理系统。2004年12月7日，OpenEmbedded项目团队成员Chris Larson将项目分为两个不同的部分：

BitBake，通用任务执行器
OpenEmbedded，BitBake使用的元数据集

如今，BitBake是OpenEmbedded项目的主要基础，该项目被用于构建和维护Angstrom Distribution等Linux发行版，还被用作Linux项目（如Yocto Project）的构建工具。

在BitBake之前，没有其他构建工具可以充分满足有抱负的嵌入式Linux发行版的需求。传统台式机Linux发行版使用的所有构建系统都缺少重要的功能，并且嵌入式空间中普遍存在的基于Buildroot的临时系统都没有可伸缩性或可维护性。

BitBake的一些重要的原始目标是：

处理交叉编译。
处理包之间的依赖关系（目标体系结构上的构建时间，本机体系结构上的构建时间和运行时）。
支持在给定的程序包中运行任意数量的任务，包括但不限于，获取上游源代码，解压缩它们，修补它们，配置它们等等。
对于Linux构建和目标系统均不可知。
与架构无关。
支持多种构建和目标操作系统（例如Cygwin，BSD等）。
是自包含的，而不是紧密集成到构建计算机的根文件系统中。
处理目标体系结构，操作系统，发行版和计算机上的条件元数据。
易于使用的工具来提供要操作的本地元数据和程序包。
易于使用BitBake在多个项目之间进行协作以进行构建。
提供继承机制以在许多软件包之间共享通用元数据。

随着时间的流逝，显然还需要一些其他要求：

处理基本配方的变体（例如本机，SDK和Multilib）。
将元数据分为多个层，并允许层增强或覆盖其他层。
允许将给定的一组输入变量表示为任务的校验和。根据该校验和，允许使用预构建的组件加速构建。

BitBake满足所有原始要求，并通过扩展基本功能以反映其他要求来满足所有其他要求。灵活性和力量一直是我们的首要任务。BitBake具有高度的可扩展性，并支持嵌入式Python代码和任意任务的执行。

1.3概念

BitBake是用Python语言编写的程序。在最高级别，BitBake解释元数据，确定要运行的任务并执行这些任务。与GNU Make相似，BitBake控制软件的构建方式。GNU Make通过“ makefiles”实现控制，而BitBake使用“ recipes”。

通过允许定义更复杂的任务（例如，组装整个嵌入式Linux发行版），BitBake扩展了GNU Make这样的简单工具的功能。

本节的其余部分介绍了几个概念，这些概念应该被理解以便更好地利用BitBake的功能。

1.3.1食谱

以文件扩展名表示的BitBake食谱是.bb最基本的元数据文件。这些配方文件为BitBake提供以下内容：

有关软件包的描述性信息（作者，主页，许可证等）
配方版本
现有依赖关系（构建和运行时依赖关系）
源代码所在的位置以及如何获取它
源代码是否需要任何补丁，在哪里可以找到它们以及如何应用它们
如何配置和编译源代码
如何将生成的工件组装到一个或多个可安装的程序包中
在目标计算机上的哪个位置安装软件包或创建的软件包

在BitBake或使用BitBake作为其构建系统的任何项目的上下文中，带有.bb扩展名的文件称为配方。

注意

术语“包装”也通常用于描述配方。但是，由于使用相同的词来描述项目的打包输出，因此最好保留一个描述性术语-“配方”。换句话说，单个“配方”文件完全能够生成许多相关但可单独安装的“程序包”。实际上，这种能力是相当普遍的。

1.3.2配置文件

用.conf扩展名表示的配置文件定义了控制项目构建过程的各种配置变量。这些文件分为几个区域，这些区域定义了机器配置，分发配置，可能的编译器调整，常规通用配置和用户配置。主要配置文件是示例bitbake.conf文件，该文件位于BitBake源代码树conf目录中。

1.3.3类

由.bbclass扩展名表示的类文件包含对在元数据文件之间共享有用的信息。BitBake源树当前带有一个名为的类元数据文件 base.bbclass。您可以在classes目录中找到此文件。在base.bbclass类文件是特殊的，因为它总是对所有的食谱和类自动包含。此类包含用于标准基本任务的定义，例如获取，解压缩，配置（默认情况下为空），编译（运行存在的任何Makefile），安装（默认情况下为空）和打包（默认情况下为空）。这些任务通常被在项目开发过程中添加的其他类覆盖或扩展。

1.3.4图层

层使您可以将不同类型的自定义相互隔离。虽然您可能会发现在单个项目中将所有内容都保留在一层中很诱人，但是元数据模块化程度越高，则应对将来的更改就越容易。

为了说明如何使用层使事物保持模块化，请考虑为支持特定目标计算机而可能进行的自定义。这些类型的定制通常驻留在特殊的层中，而不是通常的层中，即称为板级支持软件包（BSP）层。此外，例如，应将计算机定制与支持新GUI环境的配方和元数据隔离开。这种情况为您提供了两层：一层用于计算机配置，一层用于GUI环境。但是，重要的是要理解，BSP层仍然可以在GUI环境层内对配方添加特定于机器的内容，而不会因这些特定于机器的更改而污染GUI层本身。您可以通过一个食谱（BitBake append（.bbappend）文件）来完成此任务。

1.3.5追加文件

附加文件是具有.bbappend文件扩展名的文件，用于扩展或覆盖现有配方文件中的信息。

BitBake希望每个附加文件都具有一个对应的配方文件。此外，附加文件和相应的配方文件必须使用相同的根文件名。文件名只能在使用的文件类型后缀（例如formfactor_0.0.bb和 formfactor_0.0.bbappend）中有所不同。

附加文件中的信息扩展或覆盖了基础名称相似的配方文件中的信息。

为附加文件命名时，可以使用“ %”通配符来匹配配方名称。例如，假设您有一个名为如下的附加文件：

busybox_1.21.%.bbappend

该附加文件将与配方的任何busybox_1.21.x.bb版本匹配。因此，附加文件将与以下配方名称匹配：

busybox_1.21.1.bb
busybox_1.21.2.bb
busybox_1.21.3.bb

注意

“％”字符的使用受到限制，因为它只能直接在附加文件名的.bbappend部分前面使用。您不能在名称的任何其他位置使用通配符。

如果busybox配方更新为busybox_1.3.0.bb，则追加名称将不匹配。但是，如果您将附加文件命名为 busybox_1.%.bbappend，则将具有一个匹配项。

在最一般的情况下，您可以将附加文件命名为busybox_%.bbappend完全独立于版本的简单名称。

1.4获取BitBake

您可以通过几种不同的方式获得BitBake：

克隆BitBake：推荐使用Git克隆BitBake源代码存储库是获得BitBake的推荐方法。克隆存储库可轻松获得错误修复，并可以访问稳定分支和master分支。克隆BitBake之后，应该使用最新的稳定分支进行开发，因为master分支用于BitBake开发，并且可能包含不太稳定的更改。

通常，您需要一个与您使用的元数据相匹配的BitBake版本。元数据通常向后兼容但不向前兼容。

这是克隆BitBake存储库的示例：
```
$ git clone git://git.openembedded.org/bitbake
```
此命令将BitBake Git存储库克隆到名为的目录中bitbake。另外，如果您要调用新目录，则可以在命令后指定目录。这是命名目录的示例：git clonebitbakebbdev
```
$ git clone git://git.openembedded.org/bitbake bbdev
```
使用分发软件包管理系统进行安装： 不建议使用此方法，因为在大多数情况下，分发所提供的BitBake版本是BitBake存储库快照之后的多个发行版。
拍摄BitBake快照：从源代码存储库下载BitBake快照可让您访问BitBake的已知分支或版本。

注意

如前所述，克隆Git存储库是获取BitBake的首选方法。克隆存储库使将修补程序添加到稳定分支时更容易更新。

以下示例下载BitBake版本1.17.0的快照：
```
$ wget http://git.openembedded.org/bitbake/snapshot/bitbake-1.17.0.tar.gz
$ tar zxpvf bitbake-1.17.0.tar.gz
```
使用tar实用程序提取tarball后，您将拥有一个名为的目录bitbake-1.17.0。
使用构建结帐附带的BitBake：获得BitBake副本的最后一种可能性是，它已经随您结帐的基于BitBake的大型构建系统（例如Poky）一起提供。您可以检出整个构建系统，而不是手动检出各个图层并将其自己粘在一起。结帐将已经包含经过彻底测试的与其他组件兼容性的BitBake版本。有关如何检出基于BitBake的特定构建系统的信息，请参阅该构建系统的支持文档。

1.5 BitBake命令

该bitbake命令是BitBake工具的主要界面。本节介绍BitBake命令语法，并提供几个执行示例。

1.5.1用法和语法

以下是BitBake的用法和语法：

$ bitbake -h
Usage: 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.
  -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         Enable tracing of shell tasks (with 'set -x'). Also
                        print bb.note(...) messages to stdout (in addition to
                        writing them to ${T}/log.do_&lt;task&gt;).
  -D, --debug           Increase the debug level. You can specify this more
                        than once. -D sets the debug level to 1, where only
                        bb.debug(1, ...) messages are printed to stdout; -DD
                        sets the debug level to 2, where both bb.debug(1, ...)
                        and bb.debug(2, ...) messages are printed; etc.
                        Without -D, no debug messages are printed. Note that
                        -D only affects output to stdout. All debug messages
                        are written to ${T}/log.do_taskname, regardless of the
                        debug level.
  -q, --quiet           Output less log message data to the terminal. 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 (knotty, ncurses or taskexp
                        - default knotty).
  --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 xmlrpc server to bind
                        to.
  -T SERVER_TIMEOUT, --idle-timeout=SERVER_TIMEOUT
                        Set timeout to unload bitbake server due to
                        inactivity, set to -1 means no unload, default:
                        Environment variable BB_SERVER_TIMEOUT.
  --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 any running bitbake 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) to assign the name
                        automatically.
  --runall=RUNALL       Run the specified task for any recipe in the taskgraph
                        of the specified target (even if it wouldn't otherwise
                        have run).
  --runonly=RUNONLY     Run only the specified task within the taskgraph of
                        the specified targets (and any task dependencies those
                        tasks may have).

1.5.2例子

本节提供一些示例，展示如何使用BitBake。

1.5.2.1针对单个配方执行任务

对单个配方文件执行任务相对简单。您指定有问题的文件，然后BitBake解析该文件并执行指定的任务。如果您未指定任务，则BitBake将执行默认任务，即“ build”。在这样做时，BitBake遵守任务间的依赖关系。

以下命令在foo_1.0.bb配方文件上运行构建任务，这是默认任务：

$ bitbake -b foo_1.0.bb

以下命令在foo.bb配方文件上运行clean任务：

$ bitbake -b foo.bb -c clean

注意

“ -b”选项显式不处理配方依赖项。除了用于调试目的之外，建议您使用下一节介绍的语法。

1.5.2.2对一组配方文件执行任务

当要管理多个.bb文件时，会引入许多其他复杂性。显然，有一种方法可以告诉BitBake哪些文件可用，以及哪些文件要执行。还需要为每种配方提供一种表达其依赖关系的方法，包括构建时和运行时。当多个配方提供相同的功能或一个配方有多个版本时，必须有一种表达配方首选项的方法。

该bitbake命令在不使用“ –buildfile”或“ -b”时仅接受“ PROVIDES”。您无法提供其他任何东西。默认情况下，配方文件通常“提供”其“程序包名称”，如以下示例所示：

$ bitbake foo

下一个示例“提供”软件包名称，并使用“ -c”选项告诉BitBake仅执行do_clean任务：

$ bitbake -c clean foo

1.5.2.3执行任务和配方组合的列表

当您指定多个目标时，BitBake命令行支持为单个目标指定不同的任务。例如，假设您有两个目标（或配方）myfirstrecipe， mysecondrecipe并且需要BitBaketaskA为第一个配方和taskB第二个配方运行：

$ bitbake myfirstrecipe:do_taskA mysecondrecipe:do_taskB

1.5.2.4生成依赖图

BitBake能够使用dot语法生成依赖关系图。您可以使用Graphviz中的dot工具将这些图形转换为图像。

生成依赖关系图时，BitBake将两个文件写入当前工作目录：

task-depends.dot：显示任务之间的依赖关系。这些依赖项与BitBake的内部任务执行列表匹配。
pn-buildlist：显示要构建的目标的简单列表。

要停止依赖公共依赖，请使用“ -I”依赖选项，BitBake会从图中省略它们。忽略这些信息可以生成更具可读性的图形。这样，您可以DEPENDS从继承的类（例如）中从图形中删除 base.bbclass。

这是创建依赖关系图的两个示例。第二个示例省略了该图中OpenEmbedded中常见的内容：

$ bitbake -g foo

$ bitbake -g -I virtual/kernel -I eglibc foo

1.5.2.5执行多重配置构建

BitBake能够使用一个命令来构建多个映像或程序包，其中不同的目标需要不同的配置（多个配置版本）。在这种情况下，每个目标都称为“ multiconfig”。

要完成多重配置构建，必须使用构建目录中的并行配置文件分别定义每个目标的配置。这些multiconfig配置文件的位置是特定的。它们必须位于confnamed的子目录中的当前构建目录中multiconfig。以下是两个单独目标的示例：

之所以需要此文件层次结构，是因为在BBPATH 解析图层之前不会构造变量。因此，除非将配置文件放在当前工作目录中，否则无法将其用作预配置文件。

至少，每个配置文件都必须定义计算机以及BitBake用于构建的临时目录。建议的做法指示您不要与构建期间使用的临时目录重叠。

除了每个目标的单独配置文件外，还必须启用BitBake来执行多个配置构建。通过在配置文件中设置BBMULTICONFIG变量来实现启用 local.conf。举例来说，假设您在构建目录中有的配置文件target1并target2在其中定义了文件。local.conf文件中的以下语句使BitBake能够执行多个配置构建，并指定两个额外的multiconfig：

BBMULTICONFIG = "target1 target2"

目标配置文件到位并启用BitBake来执行多个配置构建后，请使用以下命令形式开始构建：

$ bitbake [mc:multiconfigname:]target [[[mc:multiconfigname:]target] ... ]

这是两个额外的multiconfig的示例：target1和target2：

$ bitbake mc::target mc:target1:target mc:target2:target

1.5.2.6启用多个配置构建依赖项

有时，在多配置构建中，目标（多配置）之间可能存在依赖关系。例如，假设为了构建用于特定体系结构的映像，需要存在另一个构建用于不同体系结构的根文件系统。换句话说，第一个多重配置的映像取决于第二个多重配置的根文件系统。这种依赖关系本质上是，构建一个多重配置的配方中的任务取决于构建另一个多重配置的配方中的任务的完成。

要在多配置版本中启用依赖关系，必须使用以下语句形式在配方中声明依赖关系：

task_or_package[mcdepends] = "mc:from_multiconfig:to_multiconfig:recipe_name:task_on_which_to_depend"

为了更好地展示如何使用此语句，请考虑一个带有两个multiconfig的示例：target1和target2：

image_task[mcdepends] = "mc:target1:target2:image2:rootfs_task"

在此示例中， from_multiconfig是“ target1”，to_multiconfig而是“ target2”。配方包含image_task的映像所在的任务取决于用于构建image2的rootfs_task的完成，该映像与“ target2”多配置关联。

设置此依赖性后，可以使用BitBake命令如下构建“ target1”多配置：

$ bitbake mc:target1:image1

该命令执行image1为“ target1” multiconfig创建所需的所有任务。由于存在依赖性，BitBake还将通过rootfs_task“ target2”多重配置版本的进行执行。

有一个配方依赖于另一个版本的根文件系统，似乎没什么用。考虑对image1配方中的语句进行以下更改：

image_task[mcdepends] = "mc:target1:target2:image2:image_task"

在这种情况下，BitBake必须image2为“ target2”构建创建，因为“ target1”构建依赖于它。

因为“ target1”和“ target2”已为多个配置版本启用，并具有单独的配置文件，所以BitBake将每个版本的工件放置在各自的临时版本目录中。