yocto 知：BitBake用户手册

修正中……

BitBake 用户手册

Richard Purdie, Chris Larson, and Phil Blundell

BitBake社区

[email protected]

Copyright © 2004-2016 Richard Purdie, Chris Larson, and Phil Blundell
这项工作是根据知识共享署名许可获得许可的。要查看此许可证的副本，请访问 http://creativecommons.org/licenses/by/2.5/ 或致函 Creative Commons, 444 Castro Street, Suite 900, Mountain View, California 94041, USA。

1. 概述

目录

1.1. 介绍
1.2. 历史和目标
1.3. 概念
1.3.1. 食谱
1.3.2. 配置文件
1.3.3. 班级
1.3.4. 图层
1.3.5. 追加文件
1.4. 获取BitBake
1.5. BitBake 命令
1.5.1. 用法和语法
1.5.2. 例子
欢迎使用 BitBake 用户手册。本手册提供有关 BitBake 工具的信息。这些信息试图尽可能独立于使用 BitBake 的系统，例如 OpenEmbedded 和 Yocto 项目。在某些情况下，手册中会使用构建系统上下文中的场景或示例来帮助理解。对于这些情况，手册清楚地说明了上下文。

1.1. 介绍

从根本上说，BitBake 是一个通用的任务执行引擎，它允许 shell 和 Python 任务在复杂的任务间依赖约束下高效并行运行。BitBake 的主要用户之一 OpenEmbedded 使用此核心并使用面向任务的方法构建嵌入式 Linux 软件堆栈。

从概念上讲，BitBake 在某些方面类似于 GNU Make，但有显着差异：

BitBake 根据提供的构建任务的元数据执行任务。元数据存储在配方 ( .bb) 和相关配方“追加” ( .bbappend) 文件、配置 ( .conf) 和底层包含 ( .inc) 文件以及类 ( .bbclass) 文件中。元数据为 BitBake 提供了有关要运行哪些任务以及这些任务之间的依赖关系的说明。

BitBake 包含一个 fetcher 库，用于从各种地方（例如本地文件、源代码控制系统或网站）获取源代码。

要构建的每个单元（例如，一个软件）的指令称为“配方”文件，包含有关该单元的所有信息（依赖项、源文件位置、校验和、描述等）。

BitBake 包括客户端/服务器抽象，可以从命令行使用，也可以作为 XML-RPC 上的服务使用，并且有几个不同的用户界面。

1.2. 历史和目标

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

BitBake，一个通用的任务执行器

OpenEmbedded，BitBake 使用的元数据集

今天，BitBake 是OpenEmbedded 项目的主要基础，该 项目被用于构建和维护 Linux 发行版，例如 Angstrom 发行版，也被用作 Linux 项目的构建工具，例如 Yocto 项目。

在 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”。

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

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

1.3.1. 食谱

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

关于包的描述信息（作者、主页、许可证等）

配方的版本

现有依赖项（构建和运行时依赖项）

源代码所在的位置以及如何获取它

源代码是否需要任何补丁，在哪里可以找到它们，以及如何应用它们

如何配置和编译源代码

在目标机器上安装一个或多个创建的包的位置

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

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

1.3.2. 配置文件

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

1.3.3. 类

由.bbclass扩展名表示的类文件 包含有助于在元数据文件之间共享的信息。BitBake 源代码树当前带有一个名为base.bbclass. 您可以在classes目录中找到该文件 。这base.bbclassclass 文件很特别，因为它总是自动包含在所有配方和类中。此类包含标准基本任务的定义，例如获取、解包、配置（默认为空）、编译（运行任何存在的 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

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

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

1.4. 获取BitBake

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

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

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

这是一个克隆 BitBake 存储库的示例：

 $ git clone git://git.openembedded.org/bitbake

此命令将 BitBake Git 存储库克隆到名为bitbake. 或者， git clone如果要调用新目录而不是bitbake. 这是命名目录的示例 bbdev：

 $ 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 或 Yocto Project。您可以检查整个构建系统，而不是手动检查各个层并将它们自己粘合在一起。结帐将包含一个 BitBake 版本，该版本已经过全面测试与其他组件的兼容性。有关如何检查特定基于 BitBake 的构建系统的信息，请参阅该构建系统的支持文档。

1.5. BitBake 命令

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

1.5.1. 用法和语法

以下是 BitBake 的用法和语法：

 $ bitbake -h
 用法：bitbake [options] [recipename/target recipe:do_task ...]

     为一组给定的目标配方（.bb 文件）执行指定的任务（默认为“构建”）。
     假设在 cwd 或 BBPATH 中有一个 conf/bblayers.conf 可用
     将提供层、BBFILES 和其他配置信息。

 选项：
   --version 显示程序的版本号并退出
   -h, --help 显示此帮助信息并退出
   -b BUILDFILE, --buildfile=BUILDFILE
                         直接从特定的 .bb 配方执行任务。
                         警告：不处理来自其他
                         食谱。
   -k, --continue 出错后尽可能继续。虽然
                         失败的目标和任何依赖它的东西都不能
                         被建造，尽可能多的将被建造在之前
                         停止。
   -a, --tryaltconfigs 通过尝试使用替代方法继续构建
                         供应商在可能的情况下。
   -f, --force 强制指定的目标/任务运行（无效
                         任何现有的图章文件）。
   -c CMD, --cmd=CMD 指定要执行的任务。确切的选项
                         可用取决于元数据。一些例子可能
                         是 'compile' 或 'populate_sysroot' 或 'listtasks' 可能
                         列出可用的任务。
   -C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMP
                         使指定任务的标记无效，例如
                         'compile' 然后运行默认任务
                         指定目标。
   -r PREFILE, --read=PREFILE
                         在 bitbake.conf 之前读取指定文件。
   -R POSTFILE, --postread=POSTFILE
                         读取 bitbake.conf 后的指定文件。
   -v, --verbose 向终端输出更多日志消息数据。
   -D, --debug 提高调试级别。您可以指定更多
                         不止一次。
   -n, --dry-run 不要执行，只是走动。
   -S SIGNATURE_HANDLER, --dump-signatures=SIGNATURE_HANDLER
                         转储签名构造信息，用
                         没有任务执行。SIGNATURE_HANDLER 参数是
                         传递给处理程序。两个常见的值是 none 和
                         printdiff 但处理程序可以定义更多/更少。没有任何
                         表示只转储签名，printdiff 表示比较
                         带有缓存的转储签名。
   -p, --parse-only 解析 BB 配方后退出。
   -s, --show-versions 显示所有配方的当前和首选版本。
   -e, --environment 显示完整的全局或每个配方环境
                         有关变量所在位置的信息
                         设置/更改。
   -g, --graphviz 保存指定的依赖树信息
                         点语法中的目标。
   -I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED
                         假设这些依赖不存在并且已经存在
                         提供（相当于 ASSUME_PROVIDED）。有用的
                         使依赖图更具吸引力
   -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
                         显示指定日志域的调试日志
   -P, --profile 配置命令并保存报告。
   -u UI, --ui=UI 要使用的用户界面（depexp、goggle、hob、knotty
                         或 ncurses - 默认结节）。
   -t SERVERTYPE, --servertype=SERVERTYPE
                         选择要使用的服务器类型（进程或 xmlrpc -
                         默认进程）。
   --token=XMLRPCTOKEN 指定要使用的连接令牌
                         连接到远程服务器。
   --revisions-changed 根据是否上游设置退出代码
                         浮动修订已更改或未更改。
   --server-only 在没有 UI 的情况下运行 bitbake，只启动一个服务器
                         （炊具）过程。
   -B BIND, --bind=BIND 要绑定到的 bitbake 服务器的名称/地址。
   --no-setscene 不运行任何 setscene 任务。sstate 将被忽略
                         以及所需的一切，构建。
   --remote-server=REMOTE_SERVER
                         连接到指定的服务器。
   -m, --kill-server 终止远程服务器。
   --observe-only 作为仅观察客户端连接到服务器。
   --status-only 查看远程bitbake服务器的状态。
   -w WRITEEVENTLOG, --write-log=WRITEEVENTLOG
                         将构建的事件日志写入 bitbake 事件
                         .json 文件。使用 ''（空字符串）分配名称
                         自动地。

1.5.2. 例子

本节提供了一些示例，说明如何使用 BitBake。

1.5.2.1. 针对单个配方执行任务

为单个配方文件执行任务相对简单。你指定有问题的文件，BitBake 解析它并执行指定的任务。如果不指定任务，BitBake 将执行默认任务，即“构建”。BitBake 执行此操作时遵守任务间依赖关系。

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

 $ bitbake -b foo_1.0.bb

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

 $ 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 能够使用dot语法生成依赖图。您可以使用Graphviz 中的dot工具 将这些图形转换为图像 。

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

package-depends.dot： 显示 BitBake 对运行时目标之间的依赖关系的了解。

pn-depends.dot： 显示构建时目标（即配方）之间的依赖关系。

task-depends.dot： 显示任务之间的依赖关系。

pn-buildlist： 显示要构建的目标的简单列表。

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

这是创建依赖关系图的两个示例。第二个示例从图中省略了 OpenEmbedded 中的公共项：

 $ bitbake -g foo

 $ bitbake -g -I 虚拟/内核 -I eglibc foo

2. 执行

目录

2.1. 解析基本配置元数据
2.2. 定位和解析食谱
2.3. 供应商
2.4. 喜好
2.5. 依赖关系
2.6. 任务清单
2.7. 执行任务
2.8. 校验和（签名）
2.9. 场景
运行 BitBake 的主要目的是生成某种输出，例如单个可安装包、内核、软件开发工具包，甚至是完整的、特定于板的可引导 Linux 映像，包括引导加载程序、内核和根文件系统。当然，您可以bitbake 使用选项执行命令，使其执行单个任务、编译单个配方文件、捕获或清除数据，或者只是返回有关执行环境的信息。

本章介绍了使用 BitBake 创建镜像时从头到尾的执行过程。使用以下命令形式启动执行过程：

 $bitbake target

有关 BitBake 命令及其选项的信息，请参阅“ BitBake 命令”部分。

笔记
在执行 BitBake 之前，您应该通过BB_NUMBER_THREADS 在项目的local.conf 配置文件中设置变量来利用构建主机上可用的并行线程执行 。

为构建主机确定此值的常用方法是运行以下命令：

 $ grep 处理器 /proc/cpuinfo

此命令返回处理器的数量，其中考虑了超线程。因此，具有超线程的四核构建主机最有可能显示八个处理器，这是您随后将分配给 的值 BB_NUMBER_THREADS。

一个可能更简单的解决方案是某些 Linux 发行版（例如 Debian 和 Ubuntu）提供该ncpus命令。

2.1. 解析基本配置元数据

BitBake 做的第一件事是解析基本配置元数据。基本配置元数据由您的项目bblayers.conf文件组成， 用于确定 BitBake 需要识别哪些层、所有必要 layer.conf文件（每个层一个）和bitbake.conf. 数据本身有多种类型：

食谱： 有关特定软件的详细信息。

类数据： 通用构建信息的抽象（例如如何构建 Linux 内核）。

配置数据： 特定于机器的设置、策略决策等。配置数据充当将所有内容绑定在一起的粘合剂。

这些layer.conf文件用于构造关键变量，例如 BBPATH 和 BBFILES。 BBPATH分别用于搜索conf和classes 目录下的配置文件和类文件 。 BBFILES用于定位配方和配方附加文件（.bb和.bbappend）。如果没有bblayers.conf文件，则假定用户已直接在环境中设置了BBPATH 和BBFILES。

接下来，bitbake.conf使用BBPATH刚刚构造的变量定位文件。该bitbake.conf文件还可以包括其他使用includeor require指令的配置文件 。

在解析配置文件之前，Bitbake 会查看某些变量，包括：

BB_ENV_WHITELIST

BB_ENV_EXTRAWHITE

BB_PRESERVE_ENV

BB_ORIGENV

BITBAKE_UI

此列表中的前四个变量与 BitBake 在任务执行期间如何处理 shell 环境变量有关。默认情况下，BitBake 会清除环境变量并提供对 shell 执行环境的严格控制。但是，通过使用前四个变量，您可以控制 BitBake 在执行任务期间允许在 shell 中使用的环境变量。请参阅“将信息传递到构建任务环境”部分以及变量词汇表中有关这些变量的信息，以获取有关它们如何工作以及如何使用它们的更多信息。

基本配置元数据是全局的，因此会影响所有执行的配方和任务。

BitBake 首先在当前工作目录中搜索可选conf/bblayers.conf配置文件。该文件应包含一个BBLAYERS 变量，该 变量是一个以空格分隔的“层”目录列表。回想一下，如果 BitBake 找不到bblayers.conf 文件，则假定用户已直接在环境中设置了BBPATH 和BBFILES变量。

对于此列表中的每个目录（层），将conf/layer.conf 定位并解析一个文件，并将 LAYERDIR 变量设置为找到该层的目录。这个想法是BBPATH 为给定的构建目录自动设置这些文件 和其他变量。

然后 BitBake 希望conf/bitbake.conf 在用户指定的BBPATH. 该配置文件通常具有包含指令以提取任何其他元数据，例如特定于体系结构、机器、本地环境等的文件。

BitBake.conf文件中只允许使用变量定义和包含指令。一些变量直接影响 BitBake 的行为。这些变量可能是从环境中设置的，具体取决于前面提到的或在配置文件中设置的环境变量。“变量词汇表”一章提供了完整的变量列表。

解析配置文件后，BitBake 使用其基本的继承机制，即通过类文件，继承一些标准类。当遇到负责获取该类的继承指令时，BitBake 会解析该类。

该base.bbclass文件始终包含在内。INHERIT 还包括在配置中使用变量指定的其他类 。BitBake以与配置文件相同的方式classes在路径下的子目录中搜索类 BBPATH文件。

了解执行环境中使用的配置文件和类文件的一个好方法是运行以下 BitBake 命令：

 $ bitbake -e > mybb.log

检查顶部mybb.log 显示您的执行环境中使用的许多配置文件和类文件。

笔记
您需要了解 BitBake 如何解析花括号。如果配方在函数内使用右花括号并且字符没有前导空格，则 BitBake 会产生解析错误。如果在 shell 函数中使用一对大括号，则结束大括号不能位于没有前导空格的行的开头。

这是导致 BitBake 产生解析错误的示例：

 fakeroot create_shar() {
     cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
 用法（）
 {
   回声“测试”
   ###### 行首的以下“}”会导致解析错误######
 }
 EOF
 }

以这种方式编写配方可以避免错误：

 fakeroot create_shar() {
     cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
 用法（）
 {
   回声“测试”
   ######下面的“}”在行首加上前导空格可以避免错误######
  }
 EOF
 }

2.2. 定位和解析食谱

在配置阶段，BitBake 将设置 BBFILES. BitBake 现在使用它来构建要解析的配方列表，以及.bbappend要应用的任何附加文件 ( )。 BBFILES是可用文件的空格分隔列表，支持通配符。一个例子是：

 BBFILES = "/path/to/bbfiles/*.bb /path/to/appends/*.bbappend"

BitBake 解析每个配方和附加文件，BBFILES并将各种变量的值存储到数据存储中。

笔记
附加文件按照它们在 BBFILES.
对于每个文件，都会制作基本配置的新副本，然后逐行解析配方。任何继承语句都会导致 BitBake 查找并解析 用作搜索路径的类文件 ( .bbclass) BBPATH。最后，BitBake 按顺序解析在 BBFILES.

一种常见的约定是使用配方文件名来定义元数据片段。例如，在bitbake.conf配方名称和版本中用于设置变量 PN和 PV：

 PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] 或 'defaultpkgname'}"
 PV = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] 或 '1.0'}"

在此示例中，名为“something_1.2.3.bb”的配方将设置 PN为“something”和 PV“1.2.3”。

当一个配方的解析完成时，BitBake 有一个配方定义的任务列表和一组由键和值组成的数据以及关于任务的依赖信息。

BitBake 不需要所有这些信息。它只需要一小部分信息即可做出有关配方的决策。因此，BitBake 会缓存它感兴趣的值，而不存储其余信息。经验表明，重新解析元数据比尝试将其写入磁盘然后重新加载要快。

在可能的情况下，后续的 BitBake 命令会重用此配方信息缓存。该缓存的有效性是通过首先计算基本配置数据的校验和（请参阅 参考资料 BB_HASHCONFIG_WHITELIST）然后检查校验和是否匹配来确定的。如果校验和匹配缓存中的内容，并且配方和类文件没有改变，Bitbake 就可以使用缓存。BitBake 然后重新加载有关配方的缓存信息，而不是从头开始重新解析它。

配方文件集合的存在允许用户拥有.bb包含相同包的多个文件存储库 。例如，人们可以轻松地使用它们来制作自己的上游存储库的本地副本，但可以进行自定义修改，而这是上游不想要的。下面是一个例子：

BBFILES = "/stuff/openembedded/*/*.bb /stuff/openembedded.modified/*/*.bb"
BBFILE_COLLECTIONS = "上游本地"
BBFILE_PATTERN_upstream = "^/stuff/openembedded/"
BBFILE_PATTERN_local = "^/stuff/openembedded.modified/"
BBFILE_PRIORITY_upstream = "5"
BBFILE_PRIORITY_local = "10"

笔记
层机制现在是收集代码的首选方法。虽然集合代码保留，但它的主要用途是设置层优先级和处理层之间的重叠（冲突）。

2.3. 提供者

假设 BitBake 已被指示执行目标并且所有配方文件都已解析，BitBake 开始弄清楚如何构建目标。BitBake 查看PROVIDES每个食谱的列表。一个PROVIDES榜单是由该配方可以知道名称的列表。每个菜谱的PROVIDES列表都是通过菜谱的PN变量隐式创建的，并通过菜谱的PROVIDES 变量显式 创建 ，这是可选的。

当配方使用 时PROVIDES，可以在一个或多个替代名称下找到该配方的功能，而不是隐式PN名称。例如，假设名为的配方keyboard_1.0.bb 包含以下内容：

 提供 += "全键盘"

这个PROVIDES秘籍的列表变成了隐式的“键盘”和显式的“全键盘”。因此，keyboard_1.0.bb可以在两个不同的名称下找到 中的功能 。

2.4. 首选项

该PROVIDES列表只是找出目标配方的解决方案的一部分。由于目标可能有多个提供者，BitBake 需要通过确定提供者偏好来确定提供者的优先级。

一个目标具有多个提供程序的常见示例是“虚拟/内核”，它位于PROVIDES每个内核配方的 列表中。每台机器通常通过在机器配置文件中使用类似于以下内容的行来选择最佳内核提供程序：

 PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"

默认 PREFERRED_PROVIDER 是与目标同名的提供者。Bitbake 遍历构建所需的每个目标，并使用此过程解析它们及其依赖项。

由于给定提供程序可能存在多个版本，因此了解如何选择提供程序变得很复杂。BitBake 默认为提供程序的最高版本。使用与 Debian 相同的方法进行版本比较。您可以使用该 PREFERRED_VERSION 变量来指定特定版本。您可以使用DEFAULT_PREFERENCE 变量来影响顺序 。

默认情况下，文件的首选项为“0”。设置DEFAULT_PREFERENCE为“-1”会使配方不太可能被使用，除非它被明确引用。设置DEFAULT_PREFERENCE为“1”使得很可能使用了配方。 PREFERRED_VERSION覆盖任何 DEFAULT_PREFERENCE设置。 DEFAULT_PREFERENCE通常用于标记更新和更具实验性的配方版本，直到它们经过足够的测试被认为是稳定的。

当给定配方有多个“版本”时，除非另有说明，BitBake 默认选择最新版本。如果相关配方的 DEFAULT_PREFERENCE 设置低于其他配方（默认为 0），则不会选择它。这允许维护配方文件存储库的一个或多个人指定他们对默认选定版本的偏好。此外，用户可以指定他们的首选版本。

如果第一个配方名为a_1.1.bb，则 PN变量将设置为“a”， PV 变量将设置为 1.1。

因此，如果a_1.2.bb存在名为的配方，BitBake 将默认选择 1.2。但是，如果您在.confBitBake 解析的文件中定义以下变量 ，则可以更改该首选项：

 PREFERRED_VERSION_a = "1.1"

笔记
一个配方通常提供两个版本——一个稳定的、编号的（和首选的）版本，以及一个从源代码存储库自动检出的版本，该版本被认为更“前沿”，但只能明确选择。

例如，在 OpenEmbedded 代码库中，有一个用于 BusyBox 的标准版本化配方文件 busybox_1.22.1.bb，但也有一个基于 Git 的版本 busybox_git.bb，它明确包含以下行

DEFAULT_PREFERENCE = "-1"

以确保编号的稳定版本始终是首选，除非开发人员另有选择。

2.5. 依赖项

每个目标BitBake的构建由多个任务，如 fetch，unpack， patch，configure，和compile。为了在多核系统上获得最佳性能，BitBake 将每个任务视为具有自己的一组依赖项的独立实体。

依赖关系是通过几个变量定义的。您可以在 本手册末尾附近的变量词汇表中找到有关 BitBake 使用的变量的信息。在基本层面上，知道 BitBake在计算依赖项时使用DEPENDS和 RDEPENDS变量就足够了 。

有关 BitBake 如何处理依赖项的更多信息，请参阅“依赖项”部分。

2.6. 任务列表

根据生成的提供者列表和依赖信息，BitBake 现在可以准确计算它需要运行哪些任务以及它需要以什么顺序运行它们。“执行任务”部分有更多关于 BitBake 如何选择下一步执行哪个任务的信息。

构建现在从 BitBake 开始，将线程分叉到BB_NUMBER_THREADS 变量中设置的限制 。只要有任务准备好运行，这些任务的所有依赖都得到满足，并且没有超过线程阈值，BitBake 就会继续分叉线程。

值得注意的是，您可以通过正确设置BB_NUMBER_THREADS变量来大大加快构建时间。

当每个任务完成时，时间戳被写入由STAMP变量指定的目录 。在后续运行中，BitBake 在其中的构建目录中查找 tmp/stamps并且不会重新运行已经完成的任务，除非发现时间戳无效。目前，仅在每个配方文件的基础上考虑无效时间戳。因此，例如，如果配置标记的时间戳大于给定目标的编译时间戳，则编译任务将重新运行。但是，再次运行编译任务对依赖该目标的其他提供程序没有影响。

邮票的确切格式是部分可配置的。在现代版本的 BitBake 中，一个哈希被附加到标记上，这样如果配置发生变化，标记就会失效，任务会自动重新运行。此散列或使用的签名由配置的签名策略管理（有关信息，请参阅“校验和（签名） ”部分）。还可以使用“stamp-extra-info”任务标志将额外的元数据附加到图章。例如，OpenEmbedded 使用此标志使某些任务特定于机器。

笔记
一些任务被标记为“nostamp”任务。运行这些任务时不会创建时间戳文件。因此，“nostamp”任务总是会重新运行。
有关任务的更多信息，请参阅“任务”部分。

2.7. 执行任务

任务可以是 shell 任务或 Python 任务。对于 shell 任务，BitBake 编写一个 shell 脚本 ，然后执行该脚本。生成的 shell 脚本包含所有导出的变量，以及扩展所有变量的 shell 函数。shell 脚本的输出到文件中 。查看运行文件中扩展的 shell 函数和日志文件中的输出是一种有用的调试技术。 $T/run.d{o}_{t}askname.pid${T}/log.do_taskname.pid

对于 Python 任务，BitBake 在内部执行任务并将信息记录到控制终端。BitBake 的未来版本会将函数写入文件，类似于处理 shell 任务的方式。日志记录的处理方式也类似于 shell 任务。

BitBake 运行任务的顺序由其任务调度程序控制。可以配置调度程序并为特定用例定义自定义实现。有关更多信息，请参阅这些控制行为的变量：

BB_SCHEDULER

BB_SCHEDULERS

可以在任务的主函数之前和之后运行函数。这是使用列出要运行的函数的任务的“prefuncs”和“postfuncs”标志来完成的。

2.8. 校验和（签名）

校验和是任务输入的唯一签名。任务的签名可用于确定是否需要运行任务。因为是任务输入的变化触发了任务的运行，BitBake 需要检测给定任务的所有输入。对于 shell 任务，事实证明这相当容易，因为 BitBake 为每个任务生成一个“运行”shell 脚本，并且可以创建一个校验和，让您很好地了解任务的数据何时发生变化。

使问题复杂化的是，校验和中不应包含某些内容。首先，存在给定任务的实际特定构建路径 - 工作目录。工作目录是否更改并不重要，因为它不应该影响目标包的输出。排除工作目录的简单方法是将其设置为某个固定值并为“运行”脚本创建校验和。BitBake 更进一步，并使用该 BB_HASHBASE_WHITELIST 变量定义了一个在生成签名时不应包含的变量列表。

另一个问题是“运行”脚本包含可能会或可能不会被调用的函数。增量构建解决方案包含计算 shell 函数之间依赖关系的代码。此代码用于将“运行”脚本修剪到最小集，从而缓解此问题并使“运行”脚本更具可读性作为奖励。

到目前为止，我们已经有了 shell 脚本的解决方案。Python 任务呢？即使这些任务更加困难，同样的方法也适用。该过程需要弄清楚 Python 函数访问哪些变量以及它调用哪些函数。同样，增量构建解决方案包含的代码首先计算变量和函数的依赖关系，然后为用作任务输入的数据创建校验和。

与工作目录的情况一样，存在应忽略依赖项的情况。对于这些情况，您可以使用如下所示的行指示构建过程忽略依赖项：

 PACKAGE_ARCHS[vardepsexclude] = "机器"

此示例确保PACKAGE_ARCHS变量不依赖于 的值MACHINE，即使它确实引用了它。

同样，在某些情况下，我们需要添加 BitBake 无法找到的依赖项。您可以使用如下所示的行来完成此操作：

  PACKAGE_ARCHS[vardeps] = "机器"

此示例显式地将MACHINE变量添加为 的依赖项PACKAGE_ARCHS。

例如，考虑使用内联 Python 的情况，其中 BitBake 无法确定依赖项。在调试模式下运行时（即使用-DDD），当 BitBake 发现无法确定其依赖关系的东西时，它会产生输出。

到目前为止，本节的讨论仅限于对任务的直接输入。基于直接输入的信息在代码中称为“basehash”。但是，仍然存在任务的间接输入的问题 - 已经构建并存在于构建目录中的内容。特定任务的校验和（或签名）需要添加特定任务所依赖的所有任务的哈希值。选择要添加的依赖项是一项策略决定。但是，其效果是生成一个主校验和，该校验和结合了 basehash 和任务依赖项的哈希。

在代码级别，有多种方式可以影响 basehash 和相关任务哈希。在 BitBake 配置文件中，我们可以给 BitBake 一些额外的信息来帮助它构建 basehash。以下语句有效地生成了一个全局变量依赖项排除列表 - 变量从未包含在任何校验和中。此示例使用来自 OpenEmbedded 的变量来帮助说明该概念：

 BB_HASHBASE_WHITELIST ?= "TMPDIR 文件路径密码 BB_TASKHASH BBPATH DL_DIR \
     SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \
     用户文件路径 STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \
     PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
     CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"

上一个示例不包括工作目录，它是 TMPDIR.

决定通过依赖链包含哪些依赖任务的哈希的规则更复杂，通常使用 Python 函数完成。中的代码meta/lib/oe/sstatesig.py显示了这方面的两个示例，还说明了如何在需要时将自己的策略插入系统。该文件定义了 OpenEmbedded Core 使用的两个基本签名生成器：“OEBasic”和“OEBasicHash”。默认情况下，BitBake 中启用了一个虚拟的“noop”签名处理程序。这意味着行为与以前的版本没有变化。 OE-Core默认情况下，通过bitbake.conf文件中的此设置使用“OEBasicHash”签名处理程序：

 BB_SIGNATURE_HANDLER ?= "OEBasicHash"

“OEBasicHash”BB_SIGNATURE_HANDLER与“OEBasic”版本相同，但将任务哈希添加到戳文件中。这会导致更改任务哈希的任何元数据更改，自动导致任务再次运行。这消除了对PR 值进行碰撞的需要 ，并且元数据的更改会在整个构建过程中自动波动。

还值得注意的是，这些签名生成器的最终结果是为构建提供一些依赖和哈希信息。这些信息包括：

BB_BASEHASH_task-taskname：配方中每个任务的基本哈希值。

BB_BASEHASH_filename:taskname：每个依赖任务的基本哈希值。

BBHASHDEPS_filename:taskname：每个任务的任务依赖关系。

BB_TASKHASH：当前正在运行的任务的哈希值。

值得注意的是，BitBake 的“-S”选项可以让您调试 Bitbake 对签名的处理。传递给 -S 的选项允许使用不同的调试模式，使用 BitBake 自己的调试功能或可能在元数据/签名处理程序本身中定义的那些。传递的最简单的参数是“none”，它会导致写出一组签名信息， STAMP_DIR 与指定的目标相对应。另一个当前可用的参数是“printdiff”，它会导致 BitBake 尝试建立最接近的签名匹配（例如在 sstate 缓存中），然后运行bitbake-diffsigs 通过匹配来确定这两个邮票树分歧的邮票和三角洲。

笔记
BitBake 的未来版本很可能会提供通过附加“-S”参数触发的其他签名处理程序。
您可以在“任务校验和和场景”部分找到有关校验和元数据的更多信息。

2.9. 场景

setscene 过程使 BitBake 能够处理“预先构建”的工件。处理和重用这些工件的能力使 BitBake 不必每次都从头开始构建东西。相反，BitBake 可以在可能的情况下使用现有的构建工件。

BitBake 需要有可靠的数据来指示工件是否兼容。上一节中描述的签名提供了一种表示工件是否兼容的理想方式。如果签名相同，则可以重用对象。

如果一个对象可以被重用，那么问题就变成了如何用预先构建的工件替换给定的任务或任务集。BitBake 通过“场景”过程解决了这个问题。

当 BitBake 被要求构建一个给定的目标时，在构建任何东西之前，它首先询问缓存信息是否可用于它正在构建的任何目标或任何中间目标。如果缓存信息可用，BitBake 将使用此信息而不是运行主要任务。

BitBake 首先调用由BB_HASHCHECK_FUNCTION 变量定义的函数，其中 包含一个任务列表和它想要构建的相应散列。这个函数被设计得很快，并返回一个它认为可以获得工件的任务列表。

接下来，对于作为可能性返回的每个任务，BitBake 执行可能的工件覆盖的任务的场景版本。任务的 Setscene 版本将字符串“_setscene”附加到任务名称。因此，例如，具有名称的任务具有名为xxx的 setscene 任务xxx_setscene。任务的 setscene 版本执行并提供返回成功或失败的必要工件。

如前所述，一个工件可以涵盖多个任务。例如，如果您已经拥有已编译的二进制文件，那么获取编译器就毫无意义。为了解决这个问题，BitBake 会BB_SETSCENE_DEPVALID 为每个成功的 setscene 任务调用该 函数，以了解它是否需要获取该任务的依赖项。

最后，在所有 setscene 任务都执行完毕后，BitBake 调用 中列出的函数 BB_SETSCENE_VERIFY_FUNCTION 以及 BitBake 认为已“覆盖”的任务列表。然后元数据可以确保这个列表是正确的，并且可以通知 BitBake 它想要运行特定的任务，而不管 setscene 结果如何。

您可以在“任务校验和和场景”部分中找到有关场景元数据的更多信息。

3. 语法和运算符

目录

3.1. 基本语法
3.1.1. 基本变量设置
3.1.2. 可变扩展
3.1.3. 设置默认值 (?=)
3.1.4. 设置弱默认值 (??=)
3.1.5. 立即变量扩展 (:=)
3.1.6. 使用空格附加 (+=) 和前置 (=+)
3.1.7. 附加 (.=) 和前置 (=.) 不带空格
3.1.8. Appending 和 Prepending（覆盖样式语法）
3.1.9. 移除（覆盖样式语法）
3.1.10. 可变标志语法
3.1.11. 内联 Python 变量扩展
3.1.12. 提供路径名
3.2. 条件语法（覆盖）
3.2.1. 条件元数据
3.2.2. 按键扩展
3.2.3. 例子
3.3. 共享功能
3.3.1. 定位包含和类文件
3.3.2. inherit指示
3.3.3. include指示
3.3.4. require指示
3.3.5. INHERIT配置指令
3.4. 职能
3.4.1. 壳函数
3.4.2. BitBake 风格的 Python 函数
3.4.3. Python 函数
3.4.4. 匿名 Python 函数
3.4.5. 类函数的灵活继承
3.5. 任务
3.5.1. 将函数提升为任务
3.5.2. 删除任务
3.5.3. 将信息传递到构建任务环境中
3.6. 变量标志
3.7. 活动
3.8. 变体 - 类扩展机制
3.9. 依赖关系
3.9.1. .bb文件内部的依赖关系
3.9.2. 构建依赖
3.9.3. 运行时依赖
3.9.4. 递归依赖
3.9.5. 任务间依赖
3.10. 使用 Python 访问数据存储变量
3.11. 任务校验和和场景
Bitbake 文件有自己的语法。语法与其他几种语言有相似之处，但也有一些独特的功能。本节介绍可用的语法和运算符并提供示例。

3.1. 基本语法

本节提供了一些基本的语法示例。

3.1.1. 基本变量设置

以下示例设置VARIABLE为“值”。这个赋值会在语句被解析时立即发生。这是一项“艰巨”的任务。

 变量 = "值"

正如预期的那样，如果您在作业中包含前导或尾随空格，则这些空格将被保留：

 变量 = "值"
 变量 = "值"

设置VARIABLE为 “” 将其设置为空字符串，而将变量设置为 " " 将其设置为空格（即这些值不同）。

 变量 = ""
 变量 = " "

3.1.2. 变量扩展

BitBake 支持使用类似于 shell 脚本的语法引用彼此内容的变量。以下是导致A 包含“aval”并B根据 的当前值评估为“preavalpost”的示例 A。

 A =“阿瓦尔”
 B = "前${A}后"

您应该意识到，无论何时B被引用，其评估都将取决于当时的状态 A。因此，B根据 的值，在前面的示例中稍后的评估可能会导致不同的值A。

3.1.3. 设置默认值 (?=)

您可以使用“?=”运算符为变量实现“更软”的赋值。这种类型的赋值允许您在解析语句时定义未定义的变量，但如果变量有值，则不考虑该值。下面是一个例子：

 A ?= "aval"

如果A在解析此语句时设置了 ，则变量保留其值。但是，如果A未设置，则将变量设置为“aval”。

笔记
这个任务是即时的。因此，如果存在对单个变量的多个“?=”赋值，则最终会使用第一个。

3.1.4. 设置弱默认值 (??=)

通过使用“??=”运算符，可以使用比上一节中“弱”的赋值。此赋值的行为与“?=”相同，只是在解析过程结束时而不是立即进行赋值。因此，当存在多个“??=”赋值时，将使用最后一个。此外，任何“=”或“?=”赋值都将覆盖用“??=”设置的值。下面是一个例子：

 A ??= "somevalue"
 A ??= "someothervalue"

如果A在解析上述语句之前设置，则变量保留其值。如果A未设置，则将变量设置为“someothervalue”。

同样，这个赋值是一个“惰性”或“弱”赋值，因为它直到解析过程结束才会发生。

3.1.5. 立即变量扩展 (:=)

“:=” 运算符导致变量的内容被立即扩展，而不是在实际使用变量时：

 T = "123"
 A := "${B} ${A} 测试 ${T}"
 T = "456"
 B = "${T} bval"
 C = "cval"
 C := "${C} 追加"

在这个例子中，A包含“测试123”，因为${B}和 $A在解析时是不确定的，这叶子“测试123”。并且，该变量C包含“cvalappend”，因为它会${C}立即扩展为“cval”。

3.1.6. 用空格附加 (+=) 和前置 (=+)

附加和前置值很常见，可以使用“+=”和“=+”运算符来完成。这些运算符在当前值和前置或附加值之间插入一个空格。

这些运算符在解析过程中立即生效。这里有些例子：

 B = "bval"
 B += "附加数据"
 C = "cval"
 C = +“测试”

该变量B包含“bval additionaldata”并C 包含“test cval”。

3.1.7. 附加 (.=) 和前置 (=.) 没有空格

如果您想在没有插入空格的情况下附加或前置值，请使用“.=”和“=”。运营商。

这些运算符在解析过程中立即生效。这里有些例子：

 B = "bval"
 B .= "附加数据"
 C = "cval"
 C =。“测试”

该变量B包含“bvaladditionaldata”并 C包含“testcval”。

3.1.8. 附加和前置（覆盖样式语法）

您还可以使用覆盖样式语法附加和预先添加变量的值。使用此语法时，不会插入空格。

这些操作符与“:=”、“.=”、“=.”、“+=”和“=+”操作符的不同之处在于它们的作用被推迟到解析完成后而不是立即应用。这里有些例子：

 B = "bval"
 B_append = "附加数据"
 C = "cval"
 C_prepend = "附加数据"
 D = "dval"
 D_append = "附加数据"

变量B变成“bval 附加数据”，C变成“附加数据cval”。该变量D成为“dvaladditional 数据”。

笔记
使用覆盖语法时，您必须控制所有间距。

3.1.9. 移除（覆盖样式语法）

您可以使用删除覆盖样式语法从列表中删除值。指定要删除的值会导致从变量中删除所有出现的该值。

当您使用此语法时，BitBake 需要一个或多个字符串。周围的空间也被删除。下面是一个例子：

 FOO = "123 456 789 123456 123 456 123 456"
 FOO_remove = "123"
 FOO_remove = "456"
 FOO2 = "abc def ghi abcdef abc def abc def"
 FOO2_remove = "abc def"

变量FOO变为“789 123456”并FOO2变为“ghi abcdef”。

3.1.10. 变量标志语法

变量标志是 BitBake 对变量属性或属性的实现。这是一种将额外信息标记到变量上的方法。您可以在“变量标志”部分中找到有关一般变量标志的更多信息。

您可以为变量标志定义、附加和预置值。前面提到的所有标准语法操作都适用于变量标志，除了覆盖样式语法（即_prepend、_append、 和_remove）。

以下是一些显示如何设置变量标志的示例：

 FOO[a] = "abc"
 FOO[b] = "123"
 FOO[a] += "456"

该变量FOO有两个标志： a和b。标志立即分别设置为“abc”和“123”。该a标志为“ABC 456”。

不需要预先定义变量标志。您可以简单地开始使用它们。一个非常常见的应用是将一些简短的文档附加到 BitBake 变量，如下所示：

 CACHE[doc] = "保存元数据缓存的目录。"

3.1.11. 内联 Python 变量扩展

您可以使用内联 Python 变量扩展来设置变量。下面是一个例子：

 DATE = "${@time.strftime('%Y%m%d',time.gmtime())}"

此示例导致将DATE 变量设置为当前日期。

此功能最常见的用途可能是从 BitBake 的内部数据字典中提取变量的值 d。以下几行分别选择包名称及其版本号的值：

 PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] 或 'defaultpkgname'}"
 PV = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] 或 '1.0'}"

3.1.12. 提供路径名

指定用于 BitBake 的路径名时，请勿使用波浪号 ("~") 字符作为主目录的快捷方式。这样做可能会导致 BitBake 无法识别路径，因为 BitBake 不会像 shell 那样扩展这个字符。

相反，请提供更完整的路径，如以下示例所示：

 BBLAYERS ?= " \
   /home/scott-lenovo/LayerA \
   ”

3.2. 条件语法（覆盖）

BitBake 用于 OVERRIDES 控制在 BitBake 解析配方和配置文件后覆盖哪些变量。本节介绍如何 OVERRIDES用作条件元数据，讨论与 的关系的键扩展 OVERRIDES，并提供一些示例以帮助理解。

3.2.1. 条件元数据

您可以使用OVERRIDES有条件地选择变量的特定版本，并有条件地附加或预先添加变量的值。

笔记
覆盖只能使用小写字符。此外，覆盖名称中不允许使用下划线，因为它们用于将覆盖彼此分开以及与变量名称分开。
选择变量： 该OVERRIDES变量是包含要满足条件的项目冒号字符分隔的列表。因此，如果您有一个以“arm”为条件的变量，并且“arm”在 中OVERRIDES，那么将使用变量的“arm”特定版本而不是非条件版本。下面是一个例子：

 覆盖=“架构：操作系统：机器”
 测试 =“默认”
 TEST_os = "osspecific"
 TEST_nooverride = "othercondvalue"

在此示例中，该OVERRIDES 变量列出了三个覆盖：“architecture”、“os”和“machine”。该变量TEST本身具有默认值“default”。您可以TEST 通过将“os”覆盖附加到变量（即TEST_os）来选择变量的特定于操作系统的版本。

为了更好地理解这一点，请考虑一个实际示例，该示例假定基于 OpenEmbedded 元数据的 Linux 内核配方文件。配方文件中的以下几行首先将内核分支变量KBRANCH 设置为默认值，然后根据构建的体系结构有条件地覆盖该值：

 KBRANCH = "标准/基础"
 KBRANCH_qemuarm = "标准/arm-versatile-926ejs"
 KBRANCH_qemumips = "标准/mti-malta32"
 KBRANCH_qemuppc = "标准/qemuppc"
 KBRANCH_qemux86 = "标准/通用电脑/基础"
 KBRANCH_qemux86-64 = "标准/common-pc-64/base"
 KBRANCH_qemumips64 = "标准/mti-malta64"

Appending 和 Prepending： BitBake 还支持根据特定项目是否在OVERRIDES. 下面是一个例子：

 依赖 = "glibc ncurses"
 覆盖=“机器：本地”
 DEPENDS_append_machine = "libmad"

在这个例子中，DEPENDS变成了“glibc ncurses libmad”。

同样，使用基于 OpenEmbedded 元数据的内核配方文件作为示例，以下几行将KERNEL_FEATURES根据架构有条件地附加到 变量：

 KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
 KERNEL_FEATURES_append_qemux86="cfg/sound.scc cfg/paravirt_kvm.scc"
 KERNEL_FEATURES_append_qemux86-64="cfg/sound.scc cfg/paravirt_kvm.scc"

3.2.2. 密钥扩展

当 BitBake 数据存储在 BitBake 扩展覆盖之前完成时，会发生密钥扩展。为了更好地理解这一点，请考虑以下示例：

 A${B} = "X"
 B = "2"
 A2 = "Y"

在这种情况下，在所有解析完成后，在处理任何覆盖之前，BitBake 扩展 ${B}为“2”。此扩展导致A2在扩展前设置为“Y”的 变为“X”。

3.2.3. 例子

尽管前面的解释显示了变量定义的不同形式，但很难弄清楚当变量运算符、条件覆盖和无条件覆盖组合在一起时会发生什么。本节介绍了一些常见的场景，并解释了通常会使用户感到困惑的可变交互。

关于覆盖和各种“附加”运算符生效的顺序，经常会出现混淆。回想一下，使用 “_append” 和 “_prepend” 的追加或前置操作不会像 “+=”、".="、"=+" 或 “=.” 那样导致立即赋值。考虑以下示例：

 覆盖 = "foo"
 A = "Z"
 A_foo_append = "X"

对于这种情况，A无条件设置为“Z”，而“X”无条件并立即附加到变量 A_foo。由于尚未应用覆盖， A_foo因此由于附加而设置为“X”并且A仅等于“Z”。

然而，应用覆盖会改变事情。由于“foo”在 中列出OVERRIDES，条件变量A被替换为“foo”版本，它等于“X”。如此有效地A_foo替换A.

下一个示例更改覆盖和附加的顺序：

 覆盖 = "foo"
 A = "Z"
 A_append_foo = "X"

对于这种情况，在处理覆盖之前， A设置为“Z”并A_append_foo 设置为“X”。但是，一旦应用了“foo”的覆盖， A就会附加“X”。因此，A变为“ZX”。请注意，没有附加空格。

下一个示例将追加和覆盖的顺序颠倒为第一个示例：

 覆盖 = "foo"
 A = "Y"
 A_foo_append = "Z"
 A_foo_append += "X"

对于这种情况，在解决任何覆盖之前， A使用立即分配将其设置为“Y”。在此立即赋值之后，A_foo设置为“Z”，然后进一步附加“X”，使变量设置为“Z X”。最后，对“foo”应用覆盖会导致条件变量A变为“Z X”（即被 A替换为A_foo）。

最后一个示例混合了一些不同的运算符：

 A = "1"
 A_append = "2"
 A_append = "3"
 A += "4"
 A .= "5"

对于这种情况，当 BitBake 多次通过代码时，追加运算符的类型会影响赋值的顺序。最初，A设置为“1 45”，因为这三个语句使用了立即数运算符。完成这些分配后，BitBake 会应用这些 _append操作。这些操作导致A成为“1 4523”。

3.3. 共享功能

BitBake 允许通过包含文件 ( .inc) 和类文件 ( .bbclass)共享元数据。例如，假设您有一项通用功能，例如要在多个配方之间共享的任务定义。在这种情况下，创建一个.bbclass 包含通用功能的文件，然后使用inherit配方中的指令来继承类将是共享任务的常用方法。

本节介绍 BitBake 提供的机制，允许您在配方之间共享功能。具体地，机构包括include， inherit，INHERIT，和 require指令。

3.3.1. 定位包含和类文件

BitBake 使用该 BBPATH 变量来定位所需的包含文件和类文件。此外，BitBake 在当前目录中搜索 include和require 指令。

笔记
该BBPATH变量类似于环境变量PATH。
为了让 BitBake 找到包含和类文件，它们需要位于“classes”子目录中，该子目录可以在BBPATH.

3.3.2. inherit指令

在编写配方或类文件时，您可以使用 inherit指令来继承类 ( .bbclass)的功能。BitBake 仅在配方和类文件（即.bb和 .bbclass）中使用时才支持此指令。

该inherit指令是指定您的配方需要哪些功能类的基本方法。例如，您可以轻松地抽象出构建使用 Autoconf 和 A​​utomake 的包所涉及的任务，并将这些任务放入您的配方可以使用的类文件中。

例如，您的配方可以使用以下指令来继承autotools.bbclass文件。类文件将包含使用 Autotools 的通用功能，这些功能可以跨配方共享：

 继承自动工具

在这种情况下，BitBake 将 classes/autotools.bbclass 在BBPATH.

笔记
通过在“inherit”语句之后执行此操作，您可以覆盖配方中继承类的任何值和函数。
如有必要，可以通过在inherit 语句后使用变量表达式来有条件地继承类。下面是一个例子：

 继承 ${VARNAME}

如果VARNAME要设置，则需要在inherit解析语句之前设置。在这种情况下实现条件继承的一种方法是使用覆盖：

 变量 = ""
 VARIABLE_someoverride = "myclass"

另一种方法是使用匿名 Python。下面是一个例子：

 Python （） {
     如果条件 == 值：
         d.setVar('变量', 'myclass')
     别的：
         d.setVar('变量', '')
 }

或者，您可以使用以下形式的内嵌 Python 表达式：

 继承 ${@'classname' if condition else ''}
 继承 ${@functionname(params)}

在所有情况下，如果表达式的计算结果为空字符串，则该语句不会触发语法错误，因为它变为无操作。

3.3.3. include指令

BitBake 理解include 指令。该指令使 BitBake 解析您指定的任何文件，并在该位置插入该文件。该指令与 Make 中的等效指令非常相似，不同之处在于如果包含行中指定的路径是相对路径，BitBake 会定位它在BBPATH.

例如，假设您需要一个配方来包含一些自测定义：

 包括 test_defs.inc

笔记
include当找不到文件时， 该指令不会产生错误。因此，我们建议，如果你是包括文件的预期存在，你应该使用 require 来代替include。这样做可确保在找不到文件时产生错误。

3.3.4. require指令

BitBake 理解require 指令。该指令的行为与include指令类似， 但如果无法找到要包含的文件，BitBake 会引发解析错误。因此，您需要的任何文件都被插入到指令所在位置正在解析的文件中。

与 BitBake 的处理方式类似 include，如果在 require 行指定的路径是相对路径，BitBake 会定位它在BBPATH.

例如，假设您有两个版本的配方（例如foo_1.2.2.bb和 foo_2.0.0.bb），其中每个版本都包含一些可以共享的相同功能。您可以创建一个名为的包含文件foo.inc ，其中包含构建“foo”所需的通用定义。您需要确保foo.inc与您的两个配方文件位于同一目录中。设置这些条件后，您可以使用require每个配方中的指令共享功能：

 需要 foo.inc

3.3.5. INHERIT配置指令

创建配置文件 ( .conf) 时，您可以使用该INHERIT指令来继承类。BitBake 仅在配置文件中使用时才支持此指令。

例如，假设您需要继承一个abc.bbclass从配置文件调用的类文件，如下所示：

 继承 += "abc"

此配置指令导致在解析期间在指令点继承命名类。与inherit指令一样， .bbclass文件必须位于BBPATH.

笔记
因为.conf在 BitBake 的执行过程中首先解析文件，使用 INHERIT继承一个类有效地全局继承该类（即对于所有配方）。
如果要使用该指令继承多个类，可以在local.conf文件的同一行中提供它们 。使用空格分隔类。以下示例显示了如何继承 autotools和pkgconfig 类：

 继承 autotools pkgconfig

3.4. 函数

与大多数语言一样，函数是用于将操作构建为任务的构建块。BitBake 支持以下类型的函数：

Shell 函数： 用 shell 脚本编写并直接作为函数、任务或两者执行的函数。它们也可以被其他 shell 函数调用。

BitBake 风格的 Python 函数： 用 Python 编写并由 BitBake 或其他 Python 函数使用bb.build.exec_func().

Python 函数： 用 Python 编写并由 Python 执行的函数。

匿名 Python 函数： 在解析过程中自动执行的 Python 函数。

无论函数类型如何，您只能在类 ( .bbclass) 和配方 ( .bbor .inc) 文件中定义它们。

3.4.1. 壳函数

用 shell 脚本编写并直接作为函数、任务或两者执行的函数。它们也可以被其他 shell 函数调用。下面是一个示例 shell 函数定义：

 some_function () {
     回声“你好世界”
 }

当您在配方或类文件中创建这些类型的函数时，您需要遵循 shell 编程规则。脚本由 执行/bin/sh，它可能不是 bash shell，但可能是诸如dash. 您不应该使用 Bash 特定的脚本 (bashisms)。

3.4.2. BitBake 风格的 Python 函数

这些函数是用 Python 编写的，由 BitBake 或其他使用 bb.build.exec_func().

一个示例 BitBake 函数是：

 python some_python_function () {
     d.setVar("TEXT", "Hello World")
     打印 d.getVar("TEXT", True)
 }

因为 Python “bb” 和 “os” 模块已经导入，所以您不需要导入这些模块。同样在这些类型的函数中，数据存储 (“d”) 是一个全局变量，并且始终自动可用。

笔记
变量表达式（例如${X}）不再在 Python 函数中展开。这种行为是有意的，目的是让您可以自由地将变量值设置为可扩展表达式，而不会过早地扩展它们。如果您确实希望在 Python 函数中扩展变量，请使用d.getVar(“X”, True). 或者，对于更复杂的表达式，请使用 d.expand().

3.4.3. Python 函数

这些函数是用 Python 编写的，并由其他 Python 代码执行。Python 函数的示例是您打算从内嵌 Python 或其他 Python 函数中调用的实用程序函数。下面是一个例子：

 def get_depends(d):
     如果 d.getVar('SOMECONDITION', True):
         返回“dependencywithcond”
     别的：
         返回“依赖”
 某些条件 = "1"
 DEPENDS = "${@get_depends(d)}"

这将导致DEPENDS 包含dependencywithcond.

以下是有关 Python 函数的一些注意事项：

Python 函数可以带参数。

BitBake 数据存储不会自动可用。因此，您必须将其作为参数传递给函数。

“bb” 和 “os” Python 模块自动可用。您不需要导入它们。

3.4.4. 匿名 Python 函数

有时在解析期间运行一些代码以设置变量或以编程方式执行其他操作很有用。为此，您可以定义一个匿名 Python 函数。这是一个基于另一个变量的值有条件地设置变量的示例：

 蟒__匿名（）{
     如果 d.getVar('SOMEVAR', True) == 'value'：
         d.setVar('ANOTHERVAR', 'value2')
 }

“__anonymous”函数名是可选的，所以下面的例子在功能上等同于上面的：

 Python （） {
     如果 d.getVar('SOMEVAR', True) == 'value'：
         d.setVar('ANOTHERVAR', 'value2')
 }

因为与其他 Python 函数不同，匿名 Python 函数是在解析过程中执行的，所以匿名 Python 函数中的“d”变量代表整个配方的数据存储。因此，您可以在此处设置变量值，这些值可以由其他函数获取。

3.4.5. 类函数的灵活继承

通过编码技术和 的使用 EXPORT_FUNCTIONS，BitBake 支持从类中导出函数，使得类函数显示为函数的默认实现，但如果继承类的配方需要定义自己的函数版本，仍然可以调用.

要了解此功能的好处，请考虑一个类定义任务函数并且您的配方继承该类的基本场景。在这个基本场景中，您的配方继承了类中定义的任务函数。如果需要，您的配方可以分别使用“_prepend”或“_append”操作添加到函数的开头和结尾，或者可以完全重新定义函数。但是，如果它重新定义了该函数，则它无法调用该函数的类版本。 EXPORT_FUNCTIONS 提供了一种机制，使函数的配方版本能够调用函数的原始版本。

要使用此技术，您需要准备好以下内容：

该类需要定义函数如下：

 classname_functionname

例如，如果您有一个类文件 bar.bbclass和一个名为 的函数 do_foo，则该类必须按如下方式定义该函数：

 bar_do_foo

该类需要包含EXPORT_FUNCTIONS 如下语句：

 EXPORT_FUNCTIONS functionname

例如，继续同一个例子， 中的语句bar.bbclass如下：

 EXPORT_FUNCTIONS do_foo

您需要从您的配方中适当地调用该函数。继续同一个例子，如果你的配方需要调用函数的类版本，它应该调用bar_do_foo. 假设do_foo是一个 shell 函数并按EXPORT_FUNCTIONS上述方式使用，配方的函数可以有条件地调用函数的类版本，如下所示：

 do_foo() {
         如果[某个条件]; 然后
                 bar_do_foo
         别的
                 # 做点别的
         菲
 }

要调用配方中定义的函数的修改版本，请将其调用为do_foo.

满足这些条件后，您的单个配方可以在类文件中定义的原始函数和配方中修改后的函数之间自由选择。如果不设置这些条件，则只能使用一种功能或另一种功能。

3.5. 任务

任务是作为函数发起的 BitBake 执行单元，并构成 BitBake 需要为给定配方运行的步骤。任务仅在配方 (.bb 或.inc) 和类 ( .bbclass) 文件中受支持。按照惯例，任务名称以字符串“do_”开头。

以下是打印日期的任务示例：

 python do_printdate() {
     导入时间
     打印时间.strftime('%Y%m%d', time.gmtime())
 }
 在 do_build 之前在 do_fetch 之后添加任务打印日期

3.5.1. 将函数提升为任务

任何功能都可以通过应用addtask命令提升为任务 。该addtask命令还描述了任务间的依赖关系。这是上一节中的函数，但使用 addtask命令将其提升为任务并定义一些依赖项：

 python do_printdate() {
     导入时间
     打印时间.strftime('%Y%m%d', time.gmtime())
 }
 在 do_build 之前在 do_fetch 之后添加任务打印日期

在示例中，函数被定义，然后被提升为任务。do_printdate任务成为该任务的依赖do_build项，即默认任务。并且，do_printdate任务依赖于do_fetch任务。do_build任务的执行导致do_printdate任务首先运行。

3.5.2. 删除任务

除了能够添加任务，您还可以删除它们。只需使用该deltask命令即可删除任务。例如，要删除前面部分中使用的示例任务，您可以使用：

 删除任务打印日期

如果使用该deltask 命令删除任务并且该任务具有依赖关系，则不会重新连接依赖关系。例如，假设你有一个名为三个任务 do_a，do_b和 do_c。此外，do_c依赖于 do_b，而后者又依赖于 do_a。鉴于这种情况，如果使用deltask to delete do_b，则do_c和 do_athrough之间的隐式依赖关系do_b 不再存在，并且do_c依赖项不会更新为 include do_a。因此，do_c之前可以自由运行 do_a。

如果您希望这些依赖项保持完整，请使用noexecvarflag 禁用任务，而不是使用deltask命令删除它：

 do_b[noexec] = "1"

3.5.3. 将信息传递到构建任务环境中

在运行任务时，BitBake 严格控制构建任务的外壳执行环境，以确保来自构建机器的不需要的污染不会影响构建。

笔记
默认情况下，BitBake 会清理环境以仅包含导出或列出在其白名单中的内容，以确保构建环境可重现且一致。您可以通过设置BB_PRESERVE_ENV 变量来防止这种“清理” 。
因此，如果您确实希望将某些内容传递到构建任务环境中，则必须执行以下两个步骤：

告诉 BitBake 将您想要从环境中加载到数据存储中。您可以通过BB_ENV_WHITELIST 和 BB_ENV_EXTRAWHITE 变量来做到这一点 。例如，假设您想阻止构建系统访问您的$HOME/.ccache 目录。以下命令将环境变量“列入白名单”， CCACHE_DIR导致 BitBack 允许该变量进入数据存储：

 导出 BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR"

告诉 BitBake 将您加载到数据存储中的内容导出到每个正在运行的任务的任务环境中。将环境中的某些内容加载到数据存储中（上一步）只会使其在数据存储中可用。要将其导出到每个正在运行的任务的任务环境，请在本地配置文件local.conf或分发配置文件中使用类似于以下内容的命令：

 导出 CCACHE_DIR

笔记
前面步骤的副作用是 BitBake 将变量记录为构建过程的依赖项，例如 setscene 校验和。如果这样做会导致不必要的任务重建，您可以将变量列入白名单，以便 setscene 代码在创建校验和时忽略依赖项。
有时，能够从原始执行环境中获取信息很有用。Bitbake 将原始环境的副本保存到名为 BB_ORIGENV.

该BB_ORIGENV变量返回一个数据存储对象，可以使用标准数据存储运算符（例如 ）查询该对象getVar(, False)。例如，数据存储对象可用于查找原始 DISPLAY变量。下面是一个例子：

 origenv = d.getVar("BB_ORIGENV", False)
 bar = origenv.getVar("BAR", False)

前面的示例BAR从原始执行环境返回。

3.6. 变量标志

变量标志 (varflags) 有助于控制任务的功能和依赖关系。BitBake 使用以下命令形式将 varflags 读取和写入数据存储：

 variable= d.getVarFlags(" variable")
 self.d.setVarFlags("FOO", {"func": True})

使用 varflags 时，应用相同的语法，但覆盖除外。换句话说，您可以像变量一样设置、附加和前置 varflags。有关详细信息，请参阅“变量标志语法”部分。

BitBake 有一组已定义的可变标志可用于配方和类。任务支持许多控制任务的各种功能的标志：

cleandirs： 应在任务运行之前创建的空目录。

依赖： 控制任务间的依赖关系。有关更多信息，请参阅 DEPENDS 变量和“任务间依赖关系”部分。

deptask： 控制任务构建时的依赖关系。有关更多信息，请参阅 DEPENDS 变量和“构建依赖项”部分。

dirs： 在任务运行之前应该创建的目录。列出的最后一个目录将用作任务的工作目录。

lockfiles： 指定在任务执行时要锁定的一个或多个锁文件。只有一个任务可以持有一个锁定文件，任何试图锁定一个已经锁定的文件的任务都将被阻塞，直到锁定被释放。您可以使用此变量标志来实现互斥。

noexec： 将任务标记为空且不需要执行。该noexec标志可用于将任务设置为依赖项占位符，或禁用在其他地方定义的在特定配方中不需要的任务。

nostamp： 告诉 BitBake 不为任务生成戳文件，这意味着该任务应该始终被执行。

postfuncs： 任务完成后调用的函数列表。

prefuncs： 任务执行前调用的函数列表。

rdepends： 控制任务间运行时依赖关系。有关更多信息RDEPENDS ，请参阅 变量、 RRECOMMENDS 变量和“任务间依赖关系”部分。

rdeptask： 控制任务运行时依赖。有关更多信息 ，请参阅 RDEPENDS 变量、 RRECOMMENDS变量和“运行时依赖项”部分。

recideptask： 与 一起设置时 recrdeptask，指定应检查其他依赖项的任务。

recrdeptask： 控制任务递归运行时依赖项。有关详细信息 ，请参阅 RDEPENDS 变量、 RRECOMMENDS变量和“递归依赖关系”部分。

stamp-extra-info： 附加到任务标记的额外标记信息。例如，OpenEmbedded 使用此标志来允许特定于机器的任务。

umask： 在其下运行任务的 umask。

几个 varflags 可用于控制如何为变量计算签名。有关此过程的更多信息，请参阅“校验和（签名） ”部分。

vardeps： 指定以空格分隔的附加变量列表，以添加到变量的依赖项以计算其签名。向此列表添加变量很有用，例如，当函数以不允许 BitBake 自动确定引用变量的方式引用变量时。

vardepsexclude： 指定一个以空格分隔的变量列表，为了计算其签名，这些变量应该从变量的依赖项中排除。

vardepvalue： 如果设置，则指示 BitBake 在计算变量签名时忽略变量的实际值而使用指定的值。

vardepvalueexclude： 指定在计算变量签名时要从变量值中排除的以管道分隔的字符串列表。

3.7. 事件

BitBake 允许在配方和类文件中安装事件处理程序。事件在操作期间的某些点被触发，例如针对给定配方（*.bb文件）的操作开始、给定任务的开始、任务失败、任务成功等。其目的是使诸如构建失败时的电子邮件通知之类的事情变得容易。

以下是打印事件名称和FILE变量内容的示例事件处理程序：

 addhandler myclass_eventhandler
 python myclass_eventhandler() {
     从 bb.event 导入 getName
     从bb导入数据
     print("事件的名称是 %s" % getName(e))
     print("我们运行的文件是 %s" % data.getVar('FILE', e.data, True))
 }

每次触发事件时都会调用此事件处理程序。e定义了一个全局变量“ ”，并且“ e.data”包含“ ”的一个实例bb.data。通过该getName(e)方法，可以获取触发事件的名称。

因为您可能只对事件的一个子集感兴趣，所以您可能会使用[eventmask]事件处理程序的标志来确保只有某些事件触发处理程序。鉴于前面的示例，假设您只希望 bb.build.TaskFailed事件触发该事件处理程序。使用标志如下：

 addhandler myclass_eventhandler
 myclass_eventhandler[eventmask] = "bb.build.TaskFailed"
 python myclass_eventhandler() {
     从 bb.event 导入 getName
     从bb导入数据
     print("事件的名称是 %s" % getName(e))
     print("我们运行的文件是 %s" % data.getVar('FILE', e.data, True))
 }

在标准构建期间，可能会发生以下常见事件：

bb.event.ConfigParsed()

bb.event.ParseStarted()

bb.event.ParseProgress()

bb.event.ParseCompleted()

bb.event.BuildStarted()

bb.build.TaskStarted()

bb.build.TaskInvalid()

bb.build.TaskFailedSilent()

bb.build.TaskFailed()

bb.build.TaskSucceeded()

bb.event.BuildCompleted()

bb.cooker.CookerExit()

以下是根据对服务器的特定请求发生的其他事件的列表：

bb.event.TreeDataPreparationStarted()

bb.event.TreeDataPreparationProgress

bb.event.TreeDataPreparationCompleted

bb.event.DepTreeGenerated

bb.event.CoreBaseFilesFound

bb.event.ConfigFilePathFound

bb.event.FilesMatchingFound

bb.event.ConfigFilesFound

bb.event.TargetsTreeGenerated

3.8. 变体 - 类扩展机制

BitBake 支持两个功能，这些功能有助于从单个配方文件创建该配方文件的多个化身，其中所有化身都是可构建的。这些功能是通过BBCLASSEXTEND 和 BBVERSIONS 变量启用的 。

笔记
The mechanism for this class extension is extremely specific to the implementation. Usually, the recipe’s PROVIDES, PN, and DEPENDS variables would need to be modified by the extension class. For specific examples, see the OE-Core native, nativesdk, and multilib classes.
BBCLASSEXTEND: This variable is a space separated list of classes used to “extend” the recipe for each variant. Here is an example that results in a second incarnation of the current recipe being available. This second incarnation will have the “native” class inherited.

 BBCLASSEXTEND = "native"

BBVERSIONS： 此变量允许单个配方从单个配方文件构建项目的多个版本。您还可以为OVERRIDES 单个版本或可选命名的版本范围指定条件元数据（使用该 机制）。下面是一个例子：

 BBVERSIONS = "1.0 2.0 git"
 SRC_URI_git = "git://someurl/somepath.git"

 BBVERSIONS = "1.0.[0-6]:1.0.0+ \ 1.0.[7-9]:1.0.7+"
 SRC_URI_append_1.0.7+ = "file://some_patch_which_the_new_versions_need.patch;patch=1"

范围的名称默认为配方的原始版本。例如，在 OpenEmbedded 中，配方文件 foo_1.0.0+.bb创建的默认名称范围为1.0.0+. 这很有用，因为范围名称不仅被放置在覆盖中，而且它也可用于元数据以在定义用于file://搜索路径的基本配方版本的变量中使用 ( FILESPATH)。

3.9. 依赖项

为了在多个进程并行执行的情况下进行高效操作，BitBake 在任务级别处理依赖项。BitBake 支持一种强大的方法来处理这些依赖项。

本节描述了几种类型的依赖机制。

3.9.1. .bb文件内部的依赖项

BitBake 使用该addtask指令来管理给定配方文件内部的依赖项。您可以使用该addtask指令来指示任务何时依赖于其他任务或其他任务何时依赖于该配方。下面是一个例子：

 在 do_build 之前在 do_fetch 之后添加任务打印日期

在这个例子中，printdate任务取决于任务的完成do_fetch 。而且，这do_build取决于printdate任务的完成情况。

3.9.2. 构建依赖项

BitBake 使用该 DEPENDS 变量来管理构建时依赖项。任务的“deptask”varflag 表示在DEPENDS执行该任务之前必须完成的每个项目的任务。下面是一个例子：

 do_configure[deptask] = "do_populate_sysroot"

在这个例子中，do_populate_sysroot 每个项目的任务DEPENDS必须完成 do_configure才能执行。

3.9.3. 运行时依赖

BitBake的使用 PACKAGES， RDEPENDS以及 RRECOMMENDS 变量管理运行时依赖。

该PACKAGES变量列出运行时包。每个这些软件包可以拥有RDEPENDS和 RRECOMMENDS运行时依赖。任务的“rdeptask”标志用于表示每个项目运行时依赖项的任务，该任务必须在该任务执行之前完成。

 do_package_qa[rdeptask] = "do_packagedata"

在前面的例子中，do_packagedata 每个项目的任务RDEPENDS必须已经完成do_package_qa才能执行。

3.9.4. 递归依赖

BitBake 使用“recrdeptask”标志来管理递归任务依赖项。BitBake 查看当前配方的构建时和运行时依赖项，查看任务的任务间依赖项，然后为列出的任务添加依赖项。一旦 BitBake 完成此操作，它就会递归地处理这些任务的依赖关系。迭代过程继续，直到发现并添加所有依赖项。

您可能不仅希望 BitBake 查找这些任务的依赖项，还希望 BitBake 查找相关任务的构建时和运行时依赖项。如果是这种情况，您需要在任务列表中引用任务名称本身：

 do_a[recrdeptask] = "do_a do_b"

3.9.5. 任务间依赖

BitBake 以更通用的形式使用“depends”标志来管理任务间的依赖关系。这种更通用的形式允许对特定任务进行相互依赖检查，而不是检查DEPENDS. 下面是一个例子：

 do_patch[depends] = "quilt-native:do_populate_sysroot"

在这个例子中，do_populate_sysroot 目标的任务quilt-native 必须已经完成， do_patch任务才能执行。

“rdepends”标志以类似的方式工作，但在运行时命名空间而不是构建时依赖命名空间中采用目标。

3.10. 使用 Python 访问数据存储变量

通常需要使用 Python 函数访问 BitBake 数据存储中的变量。Bitbake 数据存储有一个允许您进行此访问的 API。以下是可用操作的列表：

手术 描述
d.getVar(“X”, expand=False) 返回变量“X”的值。使用“expand=True”扩展值。
d.setVar(“X”, “value”) 将变量“X”设置为“值”。
d.appendVar(“X”, “value”) 将“value”添加到变量“X”的末尾。
d.prependVar(“X”, “value”) 将“value”添加到变量“X”的开头。
d.delVar(“X”) 从数据存储中删除变量“X”。
d.renameVar(“X”, “Y”) 将变量“X”重命名为“Y”。
d.getVarFlag(“X”, flag, expand=False) 然后从变量“X”中获取命名标志。使用“expand=True”扩展命名标志。
d.setVarFlag(“X”, flag, “value”) 将变量“X”的命名标志设置为“value”。
d.appendVarFlag(“X”, flag, “value”) 将“value”附加到变量“X”上的命名标志。
d.prependVarFlag(“X”, flag, “value”) 将“value”附加到变量“X”上的命名标志。
d.delVarFlag(“X”, flag) 从数据存储中删除变量“X”上的命名标志。
d.setVarFlags(“X”, flagsdict) 设置flagsdict()参数中指定的标志。 setVarFlags不清除以前的标志。将此操作视为addVarFlags.
d.getVarFlags(“X”) 返回flagsdict变量“X”的标志之一。
d.delVarFlags(“X”) 删除变量“X”的所有标志。
d.expand(expression) 扩展指定字符串表达式中的变量引用。

3.11. 任务校验和设置场景

BitBake 使用校验和（或签名）和 setscene 来确定是否需要运行任务。本节介绍该过程。为了帮助理解 BitBake 如何做到这一点，本节假设一个基于 OpenEmbedded 元数据的示例。

此列表是本手册以前工作中存在的内容的占位符。它的部分或全部可能需要集成到组成本节的小节中。现在，我只是为每个变量提供了一个类似于词汇表的简短描述。最终，这个列表消失了。

STAMP：创建图章文件的基本路径。

STAMPCLEAN Again, the base path to create stamp files but can use wildcards for matching a range of files for clean operations.

BB_STAMP_WHITELIST Lists stamp files that are looked at when the stamp policy is “whitelist”.

BB_STAMP_POLICY Defines the mode for comparing timestamps of stamp files.

BB_HASHCHECK_FUNCTION Specifies the name of the function to call during the “setscene” part of the task’s execution in order to validate the list of task hashes.

BB_SETSCENE_VERIFY_FUNCTION Specifies a function to call that verifies the list of planned task execution before the main task execution happens.

BB_SETSCENE_DEPVALID 指定 BitBake 调用的函数，该函数确定 BitBake 是否需要满足 setscene 依赖项。

BB_TASKHASH 在正在执行的任务中，此变量保存当前启用的签名生成器返回的任务的哈希值。

4. 文件下载支持

目录

4.1. 下载（获取）
4.2. 拆包
4.3. 抓取器
4.3.1. 本地文件提取器 ( file://)
4.3.2. HTTP/FTP wget fetcher ( http://, ftp://, https://)
4.3.3. CVS 获取器 ( (cvs://)
4.3.4. 颠覆 (SVN) 提取器 ( svn://)
4.3.5. Git 提取器 ( git://)
4.3.6. Git 子模块提取器 ( gitsm://)
4.3.7. ClearCase 提取器 ( ccrc://)
4.3.8. 其他提取器
4.4. 自动修订
BitBake 的 fetch 模块是一段独立的库代码，用于处理从远程系统下载源代码和文件的复杂性。获取源代码是构建软件的基石之一。因此，该模块构成了 BitBake 的重要组成部分。

当前的 fetch 模块称为“fetch2”，指的是它是 API 的第二个主要版本。原始版本已过时并已从代码库中删除。因此，在所有情况下，“fetch”在本手册中都是指“fetch2”。

4.1. 下载 (Fetch)

BitBake 在获取源代码或文件时需要执行几个步骤。fetcher 代码库按顺序处理两个不同的过程：从某处（缓存或其他方式）获取文件，然后将这些文件解包到特定位置，也许以特定方式。获取和解压文件后通常可选地进行修补。但是，此模块不包括修补。

执行这个过程的第一部分的代码，一个 fetch，看起来像下面这样：

 src_uri = (d.getVar('SRC_URI', True) or "").split()
 fetcher = bb.fetch2.Fetch(src_uri, d)
 fetcher.download()

此代码设置 fetch 类的实例。该实例使用来自SRC_URI 变量的以空格分隔的 URL 列表， 然后调用该download 方法来下载文件。

fetch 类的实例化后通常是：

 rootdir = l.getVar('WORKDIR', True)
 fetcher.unpack(rootdir)

此代码将下载的文件解压缩到指定的WORKDIR.

笔记
为方便起见，这些示例中的命名与 OpenEmbedded 使用的变量相匹配。如果您想查看上述代码的实际效果，请检查 OpenEmbedded 类文件base.bbclass。
在SRC_URI和WORKDIR 变量没有硬编码到取出器，因为这些提取器的方法可以（是）调用不同的变量名。例如，在 OpenEmbedded 中，共享状态 (sstate) 代码使用 fetch 模块来获取 sstate 文件。

download()调用 该方法时，BitBake 尝试通过按特定搜索顺序查找源文件来解析 URL：

预镜像站点： BitBake 首先使用预镜像来尝试查找源文件。这些位置是使用PREMIRRORS 变量定义的 。

源 URI： 如果预镜像失败，BitBake 使用原始 URL（例如 from SRC_URI）。

镜像站点： 如果发生获取失败，BitBake 接下来使用MIRRORS 变量定义的镜像位置 。

对于传递给 fetcher 的每个 URL，fetcher 调用处理该特定 URL 类型的子模块。当您为SRC_URI 变量提供 URL 时，这种行为可能会导致一些混乱。考虑以下两个 URL：

 http://git.yoctoproject.org/git/poky;protocol=git
 git://git.yoctoproject.org/git/poky;protocol=http

在前一种情况下，URL 被传递给wget不理解“git”的 fetcher。因此，后一种情况是正确的形式，因为 Git fetcher 确实知道如何使用 HTTP 作为传输。

以下是一些显示常用镜像定义的示例：

 预选赛？= "\
     bzr://.*/.* http://somemirror.org/sources/ \n \
     cvs://.*/.* http://somemirror.org/sources/ \n \
     git://.*/.* http://somemirror.org/sources/ \n \
     hg://.*/.* http://somemirror.org/sources/ \n \
     osc://.*/.* http://somemirror.org/sources/ \n \
     p4://.*/.* http://somemirror.org/sources/ \n \
     svn://.*/.* http://somemirror.org/sources/ \n"

 镜子 =+ "\
     ftp://.*/.* http://somemirror.org/sources/ \n \
     http://.*/.* http://somemirror.org/sources/ \n \
     https://.*/.* http://somemirror.org/sources/ \n"

值得注意的是，BitBake 支持跨 URL。可以将 HTTP 服务器上的 Git 存储库镜像为 tarball。这就是git://前面示例中的映射所做的。

由于网络访问速度较慢，Bitbake 维护了从网络下载的文件的缓存。任何非本地源文件（即从 Internet 下载）都放置在下载目录中，该目录由DL_DIR 变量指定 。

文件完整性对于复制构建至关重要。对于非本地存档下载，fetcher 代码可以验证 SHA-256 和 MD5 校验和，以确保存档已正确下载。您可以通过使用SRC_URI带有适当 varflags的变量来指定这些校验和， 如下所示：

 SRC_URI[md5sum] = " value"
 SRC_URI[sha256sum] = " value"

您还可以指定校验和作为参数 SRC_URI，如下所示：

 SRC_URI = "http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d"

如果存在多个 URI，您可以像前面的示例一样直接指定校验和，也可以命名 URL。以下语法显示了如何命名 URI：

 SRC_URI = "http://example.com/foobar.tar.bz2;name=foo"
 SRC_URI[foo.md5sum] = 4a8e0f237e961fd7785d19d07fdb994d

下载文件并检查其校验和后，将在 .done 中放置一个“.done”标记DL_DIR。BitBake 在后续构建期间使用此戳记，以避免再次下载或比较文件的校验和。

笔记
假设本地存储不会损坏数据。如果不是这种情况，就会有更大的问题需要担心。
如果 BB_STRICT_CHECKSUM 设置，则任何没有校验和的下载都会触发错误消息。该 BB_NO_NETWORK 变量可用于使任何尝试的网络访问成为致命错误，这对于检查镜像是否完整以及其他事情非常有用。

4.2. 解包

解包过程通常会在下载后立即进行。对于除 Git URL 之外的所有 URL，BitBake 使用通用 unpack方法。

您可以在 URL 中指定许多参数来控制解包阶段的行为：

unpack： 控制是否对 URL 组件进行解包。如果设置为“1”（这是默认值），则组件将被解包。如果设置为“0”，解包阶段将单独保留文件。当您希望将存档复制到其中而不是解压缩时，此参数很有用。

dos： 适用于.zip和 .jar文件，指定是否对文本文件使用DOS 行尾转换。

basepath： 指示解包阶段在解包时从源路径中剥离指定的目录。

subdir： 将特定 URL 解压到根目录中的指定子目录。

unpack 调用会自动解压和提取带有“.Z”、“.z”、“.gz”、“.xz”、“.zip”、“.jar”、“.ipk”、“.rpm”的文件。“.srpm”、“.deb”和“.bz2”扩展名以及tarball扩展名的各种组合。

如前所述，Git fetcher 有自己的解包方法，该方法已针对 Git 树进行了优化。基本上，此方法的工作原理是将树克隆到最终目录中。该过程使用引用完成，因此只需要一个 Git 元数据的中央副本。

4.3. 提取器

如前所述，URL 前缀决定了 BitBake 使用哪个 fetcher 子模块。每个子模块可以支持不同的 URL 参数，这些参数将在以下部分进行描述。

4.3.1. 本地文件提取器 ( file://)

此子模块处理以 file://. 您在 URL 中指定的文件名可以是文件的绝对路径或相对路径。如果文件名是相对的，则FILESPATH 变量的内容的 使用方式PATH与查找可执行文件的方式相同 。如果失败， FILESDIR 则用于查找适当的相关文件。

笔记
FILESDIR已弃用，可以替换为FILESPATH. 因为FILESDIR很可能会被删除，所以你不应该在任何新代码中使用这个变量。
如果找不到该文件，则假定该文件在调用DL_DIR 该download()方法时可用 。

如果指定目录，则整个目录都将被解压。

下面是几个示例 URL，第一个是相对的，第二个是绝对的：

 SRC_URI = "file://relativefile.patch"
 SRC_URI = "file:///Users/ich/very_important_software"

4.3.2. HTTP/FTP wget fetcher ( http://, ftp://, https://)

此提取器从 Web 和 FTP 服务器获取文件。在内部，fetcher 使用 wget 实用程序。

使用的可执行文件和参数由FETCHCMD_wget变量指定 ，默认为合理值。fetcher 支持参数“downloadfilename”，允许指定下载文件的名称。指定下载文件的名称对于避免在DL_DIR 处理多个具有相同名称的文件时发生冲突非常有用 。

一些示例 URL 如下所示：

 SRC_URI = "http://oe.handhelds.org/not_there.aac"
 SRC_URI = "ftp://oe.handhelds.org/not_there_as_well.aac"
 SRC_URI = "ftp://[email protected]/home/you/secret.plan"

笔记
由于 URL 参数由分号分隔，因此在解析还包含分号的 URL 时，这可能会导致歧义，例如：
SRC_URI = “http://abc123.org/git/?p=gcc/gcc.git;a=snapshot;h=a5dd47”

应通过将分号替换为“&”字符来修改此类 URL：
SRC_URI = “http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47”

在大多数情况下，这应该有效。万维网联盟 (W3C) 建议对查询中的分号和“&”进行相同的处理。请注意，由于 URL 的性质，您可能还必须指定下载文件的名称：
SRC_URI = “http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47;down​​loadfilename=myfile.bz2”

4.3.3. CVS 获取器 ( (cvs://)

这个子模块处理从 CVS 版本控制系统检出文件。您可以使用许多不同的变量对其进行配置：

FETCHCMD_cvs： 运行cvs命令时要使用的可执行文件的名称。这个名字通常是“cvs”。

SRCDATE: 获取 CVS 源代码时使用的日期。“now”的特殊值会导致每次构建时更新检出。

CVSDIR： 指定临时结帐的保存位置。位置经常DL_DIR/cvs。

CVS_PROXY_HOST： 用作命令的“代理=”参数的名称 cvs。

CVS_PROXY_PORT： 用作命令的“proxyport=”参数的端口号cvs。

除了标准的用户名和密码 URL 语法，您还可以使用各种 URL 参数配置 fetcher：

支持的参数如下：

“method”： 与 CVS 服务器通信的协议。默认情况下，此协议为“pserver”。如果“method”设置为“ext”，BitBake 会检查“rsh”参数并设置CVS_RSH. 您可以将“dir”用于本地目录。

“module”： 指定要检出的模块。您必须提供此参数。

“tag”： 描述应该使用哪个 CVS TAG 进行结帐。默认情况下，TAG 为空。

“日期”： 指定日期。如果未指定“日期”， SRCDATE 则使用配置的 来签出特定日期。“now”的特殊值会导致每次构建时更新检出。

“localdir”： 用于重命名模块。实际上，您正在重命名模块解压到的输出目录。您正在强制模块进入一个相对于 CVSDIR.

“rsh” 与 “method” 参数结合使用。

“scmdata”： 当设置为“keep”时，使 CVS 元数据保存在fetcher创建的 tarball 中。tarball 被扩展到工作目录中。默认情况下，会删除 CVS 元数据。

“fullpath”： 控制结果检出是在模块级别（这是默认值）还是在更深的路径中。

“norecurse”： 使提取器仅检出指定目录，而不会递归到任何子目录。

“port”： CVS 服务器连接的端口。

一些示例 URL 如下所示：

 SRC_URI = "cvs://CVSROOT;module=mymodule;tag=some-version;method=ext"
 SRC_URI = "cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat"

4.3.4. 颠覆 (SVN) 提取器 ( svn://)

这个 fetcher 子模块从 Subversion 源代码控制系统中获取代码。使用的可执行文件由 指定 FETCHCMD_svn，默认为“svn”。fetcher 的临时工作目录由 设置 SVNDIR，通常是DL_DIR/svn.

支持的参数如下：

“module”： 要签出的 svn 模块的名称。您必须提供此参数。您可以将此参数视为您想要的存储库数据的顶级目录。

“protocol”： 要使用的协议，默认为“svn”。其他选项是“svn+ssh”和“rsh”。对于“rsh”，还使用“rsh”参数。

“rev”： 要签出的源代码的修订版。

“日期”： 要签出的源代码的日期。特定修订通常比按日期更安全，因为它们不涉及时区（例如，它们更具确定性）。

“scmdata”： 当设置为“keep”时，使“.svn”目录在编译时可用。默认情况下，这些目录被删除。

“transportuser”： 需要时，设置传输的用户名。默认情况下，该参数为空。传输用户名与传递给 subversion 命令的主 URL 中使用的用户名不同。

以下是使用 svn 的两个示例：

 SRC_URI = "svn://svn.oe.handhelds.org/svn;module=vip;proto=http;rev=667"
 SRC_URI = "svn://svn.oe.handhelds.org/svn/;module=opie;proto=svn+ssh;date=20060126"

4.3.5. Git 提取器 ( git://)

这个 fetcher 子模块从 Git 源代码控制系统中获取代码。fetcher 的工作原理是创建远程的裸克隆 into GITDIR，通常是DL_DIR/git2. 当特定树被检出时，这个裸克隆然后在解包阶段被克隆到工作目录中。这是通过使用替代和引用来完成的，以最大限度地减少磁盘上的重复数据量并加快解包过程。使用的可执行文件可以用 FETCHCMD_git.

此提取器支持以下参数：

“协议”： 用于获取文件的协议。设置主机名时，默认值为“git”。如果未设置主机名，则 Git 协议为“文件”。您还可以使用“http”、“https”、“ssh”和“rsync”。

“nocheckout”： 当设置为“1”时，告诉提取器在解包时不检出源代码。为存在检出代码的自定义例程的 URL 设置此选项。默认值为“0”。

“rebaseable”: 表示上游 Git 仓库可以 rebase。如果修订可以与分支分离，您应该将此参数设置为“1”。在这种情况下，源镜像 tarball 是每次修订完成的，这会降低效率。重新调整上游 Git 存储库可能会导致当前修订版从上游存储库中消失。此选项提醒 fetcher 小心地保留本地缓存以备将来使用。此参数的默认值为“0”。

“nobranch”： 告诉提取器在设置为“1”时不检查分支的 SHA 验证。默认值为“0”。为引用对标记而不是分支有效的提交的配方设置此选项。

“bareclone”： 告诉fetcher将一个裸克隆克隆到目标目录中，而不检查工作树。仅提供原始 Git 元数据。此参数也暗示“nocheckout”参数。

“branch”： 要克隆的 Git 树的分支。如果未设置，则假定为“主”。分支参数的数量与名称参数的数量非常匹配。

“rev”： 用于结帐的修订。默认为“主”。

“tag”： 指定用于结帐的标签。为了正确解析标签，BitBake 必须访问网络。因此，通常不使用标签。就 Git 而言，“tag”参数的行为与“rev”参数相同。

“子路径”： 将结帐限制为树的特定子路径。默认情况下，整个树被检出。

“destsuffix”： 放置结帐的路径的名称。默认情况下，路径为git/.

以下是一些示例 URL：

 SRC_URI = "git://git.oe.handhelds.org/git/vip.git;tag=version-1"
 SRC_URI = "git://git.oe.handhelds.org/git/vip.git;protocol=http"

4.3.6. Git 子模块提取器 ( gitsm://)

此 fetcher 子模块继承自 Git fetcher，并通过获取存储库的子模块来扩展该 fetcher 的行为。 SRC_URI 传递给 Git fetcher，如“ Git Fetcher ( git://) ”部分所述。

注意事项和警告
在“ git://”和“ gitsm://”URL之间切换时，您必须清除配方。

Git Submodules fetcher 不是一个完整的 fetcher 实现。fetcher 存在一些已知问题，即它没有正确使用正常的源镜像基础设施。

4.3.7. ClearCase 提取器 ( ccrc://)

这个 fetcher 子模块从ClearCase 存储库中获取代码 。

要使用这个提取程序，确保你的食谱有适当的 SRC_URI， SRCREV和 PV设置。下面是一个例子：

 SRC_URI = "ccrc://cc.example.org/ccrc;vob=/example_vob;module=/example_module"
 SRCREV = "EXAMPLE_CLEARCASE_TAG"
 PV = "${@d.getVar("SRCREV", False).replace("/", "+")}"

fetcher 使用rcleartool或 cleartool远程客户端，具体取决于哪一个可用。

以下是SRC_URI 语句的选项：

vob：ClearCase VOB 的名称，必须包含前面的“/”字符。此选项是必需的。

module: 模块，必须在选定的 VOB 中包含前置的“/”字符。

笔记
该module和vob 选择相结合，创建load视图配置规范规则。例如，请考虑本节开头语句中的vob和 module值 SRC_URI。组合这些值会产生以下结果：
加载/example_vob/example_module

proto: 协议，可以是http或 https。

默认情况下，fetcher 创建一个配置规范。如果您希望将此规范写入默认值以外的区域，请使用CCASE_CUSTOM_CONFIG_SPEC配方中的变量来定义写入规范的位置。

笔记
SRCREV如果您指定此变量， 则将失去其功能。但是，SRCREV即使它没有定义提取的内容，它仍然用于在提取后标记存档。
以下是一些值得一提的其他行为：

使用时cleartool，登录 cleartool由系统处理。登录不需要特殊步骤。

为了rcleartool与经过身份验证的用户一起使用，在使用fetcher 之前需要“rcleartool login”。

4.3.8. 其他提取器

获取子模块也存在于以下内容中：

集市 ( bzr://)

强制 ( p4://)

使用 Git 附件 ( gitannex://) 的 树

安全 FTP ( sftp://)

安全外壳 ( ssh://)

回购 ( repo://)

振荡器 ( osc://)

水银 ( hg://)

目前没有这些较少使用的 fetcher 子模块的文档。但是，您可能会发现该代码很有用且可读。

4.4. 自动修订

我们需要记录AUTOREV和 SRCREV_FORMAT这里。

5. 变量词汇表

目录

词汇表
本章列出了 BitBake 使用的常用变量，并概述了它们的功能和内容。

笔记
以下是有关本词汇表中列出的变量的一些要点：
本词汇表中列出的变量特定于 BitBake。因此，描述仅限于该上下文。

此外，其他使用 BitBake 的系统（例如 Yocto Project 和 OpenEmbedded）中也存在变量，其名称与本词汇表中的名称相同。对于这种情况，这些系统中的变量扩展了变量的功能，如本词汇表中所述。

最后，本词汇表中提到的变量没有出现在 BitBake 词汇表中。这些其他变量是在使用 BitBake 的系统中使用的变量。

词汇表
A B C D E F G H L M O P R S T

一种
假设_提供
列出配方名称（PN 值） BitBake 不会尝试构建。相反，BitBake 假设这些配方已经构建。

在 OpenEmbedded Core 中，ASSUME_PROVIDED 主要指定不应构建的原生工具。一个例子是git-native，当指定时允许使用来自主机的 Git 二进制文件而不是构建 git-native.

乙
乙
BitBake 在配方的构建过程中执行函数的目录。

BB_ALLOWED_NETWORKS
指定一个以空格分隔的主机列表，允许提取程序使用这些主机来获取所需的源代码。以下是围绕此变量的注意事项：

此主机列表仅 BB_NO_NETWORK 在未设置或设置为“0”时使用。

存在对主机名开头的通配符匹配的有限支持。例如，下面的设置相匹配 git.gnu.org， ftp.gnu.org和 foo.git.gnu.org。

 BB_ALLOWED_NETWORKS = "*.gnu.org"

不在主机列表中的镜像将被跳过并登录到调试中。

尝试访问不在主机列表中的网络会导致失败。

使用BB_ALLOWED_NETWORKS与配合 PREMIRRORS 是非常有用的。添加要使用的主机会 PREMIRRORS导致从允许的位置获取源代码，并避免在SRC_URI 语句中出现不允许的主机时引发错误 。这是因为在SRC_URI成功从 fetchPREMIRRORS发生后 ，fetcher 不会尝试使用 中列出的主机。

BB_CONSOLELOG
指定日志文件的路径，BitBake 的用户界面在构建期间将输出写入该日志文件。

BB_当前任务
包含当前正在运行的任务的名称。名称不包括 do_前缀。

BB_DANGLINGAPPENDS_WARNONLY
定义 BitBake 如何处理附加文件 ( .bbappend) 没有相应配方文件 ( .bb) 的情况。这种情况经常发生在层不同步时（例如，oe-core碰撞配方版本，旧配方不再存在，另一层尚未更新到新版本的配方）。

默认的致命行为是最安全的，因为它是在不同步的情况下的理智反应。重要的是要意识到何时不再应用您的更改。

BB_DEFAULT_TASK
未指定时使用的默认任务（例如，使用-c命令行选项）。指定的任务名称不应包含 do_前缀。

BB_DISKMON_DIRS
在构建期间监控磁盘空间和可用 inode，并允许您根据这些参数控制构建。

默认情况下禁用磁盘空间监控。设置此变量时，请使用以下形式：

 BB_DISKMON_DIRS = ",, [...]"

 在哪里：

    <动作> 是：
       ABORT：在以下情况下立即中止构建
                  一个门槛被打破。
       STOPTASKS：在当前结束后停止构建
                  执行任务完成时
                  一个门槛被打破。
       警告：发出警告但继续
                  当阈值被打破时构建。
                  随后的警告被发布为
                  由定义
                  BB_DISKMON_WARNINTERVAL变量，
                  必须定义。

    <目录> 是：
       您选择的任何目录。您可以指定一个或
       通过分隔更多要监视的目录
       带空格的分组。如果有两个目录
       在同一台设备上，只有第一个目录
       被监控。

    <阈值> 是：
       最小可用磁盘空间，
       空闲 inode 的最小数量，或
       两个都。您必须至少指定一个。到
       省略一个或另一个，只需省略值。
       使用 G、M、K 指定 Gbytes 的阈值，
       分别为 MB 和 KB。如果你这样做
       未指定 G、M 或 K，Kbytes 由
       默认。不要使用 GB、MB 或 KB。

这里有些例子：

 BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K"
 BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G"
 BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K"

只有当您还设置了BB_DISKMON_WARNINTERVAL变量时，第一个示例才有效。此示例导致构建系统在磁盘空间$TMPDIR低于1GB或可用空闲inode低于100KB时立即中止。因为变量提供了两个目录，所以当${SSTATE_DIR}目录中的磁盘空间低于 1 GB 或空闲 inode 数低于 100 KB时，构建系统也会发出警告 。随后的警告在规定的时间间隔内发出BB_DISKMON_WARNINTERVAL 多变的。

当${TMPDIR} 目录中的最小磁盘空间低于 1 GB时，第二个示例在所有当前正在执行的任务完成后停止构建。在这种情况下，不会对空闲 inode 进行磁盘监控。

当${TMPDIR}目录中的空闲 inode 数量低于 100 KB时，最后一个示例立即中止构建。在这种情况下，不会对目录本身进行磁盘空间监视。

BB_DISKMON_WARNINTERVAL
定义磁盘空间和空闲 inode 警告间隔。

如果要使用该 BB_DISKMON_WARNINTERVAL变量，则还必须使用该 BB_DISKMON_DIRS变量并将其操作定义为“WARN”。在构建期间，每次磁盘空间或空闲 inode 数量进一步减少相应的时间间隔时，都会发出后续警告。

如果您不提供BB_DISKMON_WARNINTERVAL 变量并且确实使用BB_DISKMON_DIRS了“WARN”操作，则磁盘监视间隔默认如下：

 BB_DISKMON_WARNINTERVAL = "50M,5K"

在配置文件中指定变量时，请使用以下形式：

 BB_DISKMON_WARNINTERVAL = ","

 在哪里：

     是：
       以任一表示的记忆间隔
       G、M 或 K 表示 Gbytes、Mbytes 或 Kbytes，
       分别。不能使用 GB、MB 或 KB。

     是：
       以任一方式表示的空闲 inode 的间隔
       G、M 或 K 表示 Gbytes、Mbytes 或 Kbytes，
       分别。不能使用 GB、MB 或 KB。

下面是一个例子：

 BB_DISKMON_DIRS = "警告,${SSTATE_DIR},1G,100K"
 BB_DISKMON_WARNINTERVAL = "50M,5K"

每当可用磁盘空间进一步减少 50 MB 或目录中的空闲 inode 数量进一步减少 5 KB 时，这些变量会导致 BitBake 发出后续警告 ${SSTATE_DIR}。每次达到超出初始警告（即 1 GB 和 100 KB）的相应间隔时，都会根据间隔发出后续警告。

BB_ENV_WHITELIST
指定允许从外部环境进入 BitBake 数据存储的内部变量白名单。如果未指定这个变量的值（这是默认值），以下列表用于： BBPATH， BB_PRESERVE_ENV， BB_ENV_WHITELIST，和 BB_ENV_EXTRAWHITE。

笔记
您必须在外部环境中设置此变量才能使其工作。
BB_ENV_EXTRAWHITE
指定一组额外的变量以允许通过（白名单）从外部环境进入 BitBake 的数据存储。此变量列表位于 中设置的内部列表的顶部 BB_ENV_WHITELIST。

笔记
您必须在外部环境中设置此变量才能使其工作。
BB_FETCH_PREMIRRORONLY
当设置为“1”时，会导致 BitBake 的 fetcher 模块只搜索 PREMIRRORS 文件。BitBake 不会搜索 main SRC_URI 或 MIRRORS.

BB_FILENAME
包含拥有当前正在运行的任务的配方的文件名。例如，如果do_fetch驻留在 中的任务my-recipe.bb正在执行，则BB_FILENAME变量包含“/foo/path/my-recipe.bb”。

BB_GENERATE_MIRROR_TARBALLS
将 Git 存储库的 tarball（包括 Git 元数据）放置在 DL_DIR 目录中。任何希望创建源镜像的人都希望启用此变量。

出于性能原因，创建和放置 Git 存储库的 tarball 不是 BitBake 的默认操作。

 BB_GENERATE_MIRROR_TARBALLS = "1"

BB_HASHCONFIG_WHITELIST
列出从基本配置校验和中排除的变量，用于确定是否可以重用缓存。

BitBake 确定是否重新解析主要元数据的方法之一是通过基本配置数据的数据存储中变量的校验和。在检查是否重新解析并因此重建缓存时，您通常希望排除一些变量。例如，您通常会排除 TIME并且DATE 因为这些变量总是在变化。如果您不排除它们，BitBake 将永远不会重用缓存。

BB_HASHBASE_WHITELIST
列出从校验和和相关性数据中排除的变量。因此，被排除的变量可以在不影响校验和机制的情况下更改。一个常见的例子是构建路径的变量。BitBake 的输出不应该（通常不）依赖于它的构建目录。

BB_HASHCHECK_FUNCTION
指定在任务执行的“setscene”部分调用的函数名称，以验证任务哈希列表。该函数返回应执行的 setscene 任务列表。

在代码执行的这一点上，目标是快速验证给定的 setscene 函数是否可能工作。一次检查 setscene 函数列表比调用许多单个任务更容易。返回的列表不需要完全准确。给定的场景任务稍后仍可能失败。但是，返回的数据越准确，构建的效率就越高。

BB_INVALIDCONF
与ConfigParsed事件结合使用 以触​​发重新解析基础元数据（即所有配方）。该ConfigParsed事件可以设置变量来触发重新解析。您必须小心避免使用此功能的递归循环。

BB_LOGFMT
指定保存到 . 默认情况下，变量未定义，日志文件名使用以下形式创建： ${T}BB_LOGFMT

 日志.{任务}.{pid}

如果要强制日志文件采用特定名称，可以在配置文件中设置此变量。

BB_NICE_LEVEL
允许 BitBake 以特定优先级（即良好级别）运行。系统权限通常意味着 BitBake 可以降低其优先级，但不会再次提高它。有关BB_TASK_NICE_LEVEL 其他信息，请参阅 。

BB_NO_NETWORK
在 BitBake fetcher 模块中禁用网络访问。禁用此访问后，任何尝试访问网络的命令都会出错。

禁用网络访问对于测试源镜像、在未连接到 Internet 时运行构建以及在某些类型的防火墙环境中运行时非常有用。

BB_NUMBER_THREADS
BitBake 应在任一时间并行运行的最大任务数。如果您的主机开发系统支持多核，一个好的经验法则是将此变量设置为核数的两倍。

BB_NUMBER_PARSE_THREADS
设置解析时 BitBake 使用的线程数。默认情况下，线程数等于系统上的内核数。

BB_ORIGENV
包含运行 BitBake 的原始外部环境的副本。在将任何列入白名单的变量值过滤到 BitBake 的数据存储区之前，会进行复制。

笔记
该变量的内容是一个数据存储对象，可以使用正常的数据存储操作进行查询。
BB_PRESERVE_ENV
禁用白名单，而是允许所有变量从外部环境进入 BitBake 的数据存储。

笔记
您必须在外部环境中设置此变量才能使其工作。
BB_RUNFMT
指定保存到 . 默认情况下，变量未定义，运行文件名使用以下形式创建： ${T}BB_RUNFMT

 运行.{task}.{pid}

如果要强制运行文件采用特定名称，可以在配置文件中设置此变量。

BB_RUNTASK
包含当前正在执行的任务的名称。该值不包括“do_”前缀。例如，如果当前正在执行的任务是 do_config，则值为“config”。

BB_调度程序
选择用于调度 BitBake 任务的调度程序的名称。存在三种选择：

基本- 一切都源自的基本框架。使用此选项会导致任务在解析时按数字排序。

speed - 首先执行有更多任务依赖的任务。“速度”选项是默认选项。

完成- 使调度程序在构建开始后尝试完成给定的配方。

BB_调度程序
定义要导入的自定义调度程序。自定义调度程序需要从RunQueueScheduler类派生 。

有关如何选择调度程序的信息，请参阅 BB_SCHEDULER 变量。

BB_SETSCENE_DEPVALID
指定 BitBake 调用的函数，该函数确定 BitBake 是否需要满足 setscene 依赖项。

在运行 setscene 任务时，BitBake 需要知道该 setscene 任务的哪些依赖项也需要运行。是否还需要运行依赖项高度依赖于元数据。此变量指定的函数根据是否需要满足依赖关系返回“True”或“False”。

BB_SETSCENE_VERIFY_FUNCTION
指定要调用的函数，该函数在主任务执行发生之前验证计划的任务执行列表。一旦 BitBake 具有已运行且成功或失败的 setscene 任务列表，就会调用该函数。

该功能允许检查任务列表以查看它们是否有意义。即使 BitBake 计划跳过任务，函数的返回值也可以强制 BitBake 运行任务，这在某些元数据定义的情况下是必要的。

BB_SIGNATURE_EXCLUDE_FLAGS
列出可以安全地从数据存储中键的校验和和依赖项数据中排除的变量标志 (varflags)。为数据存储中的键生成校验和或依赖项数据时，针对该键设置的标志通常包含在校验和中。

有关 varflags 的更多信息，请参阅“变量标志”部分。

BB_SIGNATURE_HANDLER
定义 BitBake 使用的签名处理程序的名称。签名处理程序定义了图章文件的创建和处理方式，签名是否以及如何合并到图章中，以及签名本身是如何生成的。

可以通过将从类派生的SignatureGenerator类注入全局命名空间来添加新的签名处理程序 。

BB_SRCREV_POLICY
定义 fetcher 在与源控制系统和动态源修订交互时的行为。该BB_SRCREV_POLICY变量在没有网络的情况下工作时很有用。

可以使用以下两种策略之一设置变量：

缓存- 保留系统先前获得的值，而不是每次都查询源控制系统。

clear - 每次都查询源代码控制系统。使用此策略，没有缓存。“清除”策略是默认设置。

BB_STAMP_POLICY
定义用于如何比较戳文件的时间戳的模式。您可以将变量设置为以下模式之一：

perfile - 时间戳比较仅在特定配方的时间戳之间进行。这是默认模式。

full - 对所有依赖项进行时间戳比较。

白名单- 除了对BB_STAMP_WHITELIST 变量中列出的配方进行时间戳比较之外，与“完整”模式相同 。

笔记
随着场景任务的引入，邮票政策在很大程度上已经过时了。
BB_STAMP_WHITELIST
列出当戳策略模式设置为“白名单”时比较戳文件时间戳的文件。有关邮票政策的信息，请参阅 BB_STAMP_POLICY 变量。

BB_STRICT_CHECKSUM
为非本地 URL 设置更严格的校验和机制。将此变量设置为一个值会导致 BitBake 在遇到未指定至少一个校验和的非本地 URL 时报告错误。

BB_TASK_IONICE_LEVEL
允许调整任务的输入/输出优先级。在 Autobuilder 测试期间，由于 I/O 不足，任务可能会发生随机故障。这些故障发生在各种 QEMU 运行时超时期间。您可以使用该BB_TASK_IONICE_LEVEL 变量来调整这些任务的 I/O 优先级。

笔记
BB_TASK_NICE_LEVEL 除了任务的 I/O 优先级之外， 此变量的工作方式与变量类似 。
设置变量如下：

 BB_TASK_IONICE_LEVEL = " class. prio"

对于class，默认值为“2”，这是尽力而为。您可以将“1”用于实时，“3”用于空闲。如果要使用实时，则必须具有超级用户权限。

对于prio，您可以使用从最高优先级“0”到最低优先级“7”的任何值。默认值为“4”。您不需要任何特殊权限即可使用此优先级值范围。

笔记
为了使您的 I/O 优先级设置生效，您需要为后备块设备选择完全公平队列 (CFQ) 调度程序。要选择调度程序，请使用以下命令表，device设备在哪里（例如 sda、sdb 等）：
$ sudo sh -c “echo cfq > /sys/block/ device/queu/scheduler

BB_TASK_NICE_LEVEL
允许特定任务更改其优先级（即好级别）。

您可以将此变量与任务覆盖结合使用来提高或降低特定任务的优先级。例如，在 Yocto 项目 自动构建器上，与构建任务相比，图像中的 QEMU 仿真具有更高的优先级，以确保图像在加载的系统上不会超时。

BB_TASKHASH
在正在执行的任务中，此变量保存当前启用的签名生成器返回的任务的哈希值。

BB_VERBOSE_LOGS
控制构建过程中 BitBake 的详细程度。如果设置，shell 脚本回显命令和 shell 脚本输出出现在标准输出 (stdout) 上。

BB_WORKERCONTEXT
指定当前上下文是否正在执行任务。在执行任务时，BitBake 将此变量设置为“1”。当任务在解析或事件处理期间处于服务器上下文中时，不会设置该值。

BBCCLASSEND
允许您扩展配方，以便它构建软件的变体。这些来自 OpenEmbedded Core 元数据的配方变体的一些示例是“本地”，例如 quilt-native，它是为在构建系统上运行而构建的 Quilt 副本；“交叉”，例如gcc-cross，它是一个编译器，用于在构建机器上运行，但生成在目标上运行的二进制文件MACHINE；“nativesdk”，它针对的是 SDK 机器而不是 MACHINE; 和形式为“ multilib:multilib_name”的“multilibs ”。

要使用最少的代码构建配方的不同变体，通常就像将变量添加到配方中一样简单。这里有两个例子。“原生”变体来自 OpenEmbedded Core 元数据：

 BBCLASSEXTEND =+ "native nativesdk"
 BBCLASSEXTEND =+ "multilib: multilib_name"

BBDEBUG
将 BitBake 调试输出级别设置为由-d命令行选项递增的特定值。

笔记
您必须在外部环境中设置此变量才能使其工作。
BBFILE_COLLECTIONS
列出已配置层的名称。这些名称用于查找其他BBFILE_* 变量。通常，每个层将其名称附加到其conf/layer.conf文件中的此变量 。

BBFILE_PATTERN
扩展以匹配来自BBFILES 特定层的文件的变量 。该变量在conf/layer.conf文件中使用，并且必须以特定层的名称作为后缀（例如 BBFILE_PATTERN_emenlow）。

BBFILE_PRIORITY
为每一层中的配方文件分配优先级。

此变量在同一配方出现在多个层中的情况下很有用。设置此变量允许您将一个层与包含相同配方的其他层进行优先级排序 - 有效地让您控制多个层的优先级。通过此变量建立的优先级与配方的版本（PV变量）无关。例如，具有较高PV值的配方但BBFILE_PRIORITY设置为具有较低优先级的图层仍然具有较低的优先级。

BBFILE_PRIORITY变量的值越大，优先级越高。例如，值 6 的优先级高于值 5。如果未指定，BBFILE_PRIORITY则根据层依赖设置该LAYERDEPENDS变量（有关更多信息，请参阅该 变量。如果未指定无依赖层的默认优先级，则默认优先级为定义的最低优先级 + 1（如果未定义优先级，则为 1）。

提示
您可以使用该命令bitbake-layers show-layers列出所有已配置的层及其优先级。
BBFILES
BitBake 用于构建软件的配方文件列表。

包含
包含以空格分隔的所有文件的列表，其中包含 BitBake 的解析器在解析当前文件期间包含的所有文件。

BBINCLUDELOGS
如果设置为一个值，则在报告失败的任务时启用打印任务日志。

BBINCLUDELOGS_LINES
如果 BBINCLUDELOGS 已设置，则指定在报告失败任务时要打印的任务日志文件中的最大行数。如果不设置BBINCLUDELOGS_LINES，则打印整个日志。

BBLAYERS
列出要在构建期间启用的层。该变量bblayers.conf在构建目录的配置文件中定义。下面是一个例子：

 BBLAYERS = " \
   /home/scottrif/poky/meta \
   /home/scottrif/poky/meta-yocto \
   /home/scottrif/poky/meta-yocto-bsp \
   /home/scottrif/poky/meta-mykernel \
   ”

此示例启用四个图层，其中一个是名为 的自定义用户定义图层meta-mykernel。

BBLAYERS_FETCH_DIR
设置存储图层的基本位置。默认情况下，此位置设置为 ${COREBASE}。此设置与bitbake-layers layerindex-fetch并告知bitbake-layers放置获取的图层的位置一起使用 。

BBMASK
防止 BitBake 处理配方和配方附加文件。

您可以使用该BBMASK变量来“隐藏”这些.bb和 .bbappend文件。BitBake 忽略与任何表达式匹配的任何配方或配方附加文件。就好像 BitBake 根本没有看到它们一样。因此，BitBake 不会解析或以其他方式使用匹配文件。

您提供的值将传递给 Python 的正则表达式编译器。将表达式与文件的完整路径进行比较。有关完整的语法信息，请参阅http://docs.python.org/release/2.3/lib/re-syntax.html 上的Python 文档 。

以下示例使用完整的正则表达式告诉 BitBake 忽略目录中的所有配方和配方附加文件meta-ti/recipes-misc/ ：

 BBMASK = "meta-ti/recipes-misc/"

如果要屏蔽多个目录或配方，可以指定多个正则表达式片段。下一个示例屏蔽了多个目录和单个配方：

 BBMASK += "/meta-ti/recipes-misc/meta-ti/recipes-ti/packagegroup/"
 BBMASK += "/meta-oe/recipes-support/"
 BBMASK += "/meta-foo/.*/openldap"
 BBMASK += "opencv.*\.bbappend"
 BBMASK += "lzma"

笔记
指定目录名称时，请使用尾部斜杠字符以确保仅匹配该目录名称。
BBPATH
BitBake 使用它来定位类 ( .bbclass) 和配置 ( .conf) 文件。这个变量类似于 PATH变量。

如果从构建目录之外的目录运行 BitBake，则必须确保设置 BBPATH为指向构建目录。像设置任何环境变量一样设置变量，然后运行 ​​BitBake：

 $BBPATH=" build_directory"
 $ 导出 BBPATH
 $bitbake target

BBSERVER
指向运行内存驻留 BitBake 的服务器。该变量仅在您使用内存驻留 BitBake 时使用。

BBT目标
允许您使用配置文件添加到要构建的命令行目标配方列表。

BBVERSIONS
允许单个配方从单个配方文件构建项目的多个版本。您还可以使用该OVERRIDES 机制为单个版本或可选命名的版本范围指定条件元数据 。

有关 的更多信息BBVERSIONS，请参阅“变体 - 类扩展机制”部分。

BITBAKE_UI
用于指定运行 BitBake 时使用的 UI 模块。使用此变量等同于使用 -u命令行选项。

笔记
您必须在外部环境中设置此变量才能使其工作。
建筑名称
分配给构建的名称。该名称默认为构建开始时的日期时间戳，但可以由元数据定义。

BZRDIR
存储从 Bazaar 系统检出的文件的目录。

C
缓存
指定 BitBake 用于存储元数据缓存的目录，因此无需在每次启动 BitBake 时对其进行解析。

CVSDIR
CVS系统下检出的文件存放的目录。

D
DEFAULT_PREFERENCE
指定配方选择优先级的弱偏差。

这个变量的最常见用法是在一个软件的开发版本的配方中将其设置为“-1”。在没有PREFERRED_VERSION 用于构建开发版本的情况下，以这种方式使用变量会导致默认情况下构建配方的稳定 版本。

笔记
由 提供的偏差DEFAULT_PREFERENCE 很弱，BBFILE_PRIORITY 如果该变量在包含相同配方的不同版本的两个层之间不同，则会被覆盖 。
取决于
列出配方的构建时依赖项（即其他配方文件）。

考虑这个名为“a”和“b”的配方的简单示例，它们生成名称相似的包。在这个例子中，DEPENDS 语句出现在“a”配方中：

 依赖 = "b"

在这里，依赖关系使得 do_configure配方“a”的do_populate_sysroot 任务依赖于配方“b”的任务。这意味着当配方“a”配置自身时，配方“b”放入 sysroot 的任何内容都可用。

有关运行时依赖项的信息，请参阅 RDEPENDS 变量。

说明
食谱的详细说明。

DL_DIR
构建过程用于存储下载的中央下载目录。默认情况下，DL_DIR获取适合镜像除 Git 存储库之外的所有文件的文件。如果您想要 Git 存储库的 tarball，请使用该 BB_GENERATE_MIRROR_TARBALLS 变量。

乙
EXCLUDE_FROM_WORLD
指示 BitBake 从世界构建中排除配方（即 bitbake world）。在世界构建期间，BitBake 定位、解析和构建在bblayers.conf配置文件中公开的每一层中找到的所有配方 。

要使用此变量从世界构建中排除配方，请在配方中将变量设置为“1”。

笔记
添加到的配方EXCLUDE_FROM_WORLD 可能仍会在世界构建期间构建，以满足其他配方的依赖性。添加配方以EXCLUDE_FROM_WORLD 仅确保配方不会显式添加到世界构建中的构建目标列表中。
F
假根
包含在 fakeroot 环境中运行 shell 脚本时使用的命令。该FAKEROOT变量已过时并已被其他FAKEROOT*变量替换 。有关更多信息，请参阅词汇表中的这些条目。

FAKEROOTBASEENV
列出FAKEROOTCMD 在 fakeroot 环境中启动 bitbake-worker 进程定义的命令时要设置的环境变量 。

FAKEROOTCMD
包含在 fakeroot 环境中启动 bitbake-worker 进程的命令。

假根目录
列出在 fakeroot 环境中运行任务之前要创建的目录。

FAKEROOTENV
列出在 fakeroot 环境中运行任务时要设置的环境变量。有关环境变量和 fakeroot 环境的其他信息，请参阅 FAKEROOTBASEENV 变量。

FAKEROOTNOENV
列出运行不在 fakeroot 环境中的任务时要设置的环境变量。有关环境变量和 fakeroot 环境的其他信息，请参阅 FAKEROOTENV 变量。

FETCHCMD
定义 BitBake fetcher 模块在运行 fetch 操作时执行的命令。当您使用变量（例如FETCHCMD_git 或FETCHCMD_svn）时，您需要使用覆盖后缀。

文件
指向当前文件。BitBake 在解析过程中设置此变量以识别正在解析的文件。BitBake 还会在执行配方时设置此变量以识别配方文件。

文件目录
指定 BitBake 在搜索补丁和文件时使用的目录。“本地”提取器模块在处理file://URL 时，如果使用 FILESPATH.

笔记
该FILESDIR变量已弃用，您应该 FILESPATH在所有新代码中使用。
文件路径
指定 BitBake 在搜索补丁和文件时使用的目录。“本地”提取器模块在处理file://URL时使用这些目录。该变量的行为类似于 shellPATH 环境变量。该值是按从左到右的顺序搜索的以冒号分隔的目录列表。

G
目录
克隆时存储 Git 存储库的本地副本的目录。

H
HGDIR
从 Mercurial 系统检出的文件的存储目录。

主页
可以找到有关配方正在构建的软件的更多信息的网站。

一世
继承
导致在解析过程中此时继承命名类。该变量仅在配置文件中有效。

升
层依赖
列出此配方所依赖的层，以空格分隔。或者，您可以通过将其添加到带有冒号的层名称末尾来为依赖项指定特定层版本（例如， 在这种情况下要与之进行比较的“anotherlayer:3” ）。如果缺少任何依赖项或版本号不完全匹配（如果指定），BitBake 会产生错误。LAYERVERSION_anotherlayer

您在conf/layer.conf文件中使用此变量。您还必须使用特定的图层名称作为变量的后缀（例如LAYERDEPENDS_mylayer）。

图层目录
在layer.conf配置文件中使用时，此变量提供当前层的路径。此变量在外部不可用，layer.conf 并且在文件解析完成后会立即扩展引用。

图层版本
（可选）将图层的版本指定为单个数字。您可以在LAYERDEPENDS 另一个层中使用此变量 ，以依赖于该层的特定版本。

您在conf/layer.conf文件中使用此变量。您还必须使用特定的图层名称作为变量的后缀（例如LAYERDEPENDS_mylayer）。

许可证
配方的源许可证列表。

米
镜子
指定 BitBake 从中获取源代码的其他路径。当构建系统搜索源代码时，它首先尝试本地下载目录。如果该位置失败，构建系统会尝试由PREMIRRORS、上游源定义的位置，然后按MIRRORS该顺序尝试由 指定的位置 。

MULTI_PROVIDER_WHITELIST
允许您抑制在构建提供相同输出的两个单独配方时引起的 BitBake 警告。

当构建两个不同的配方时，Bitbake 通常会发出警告，每个配方都提供相同的输出。这种情况通常是用户不想要的。但是，确实存在有意义的情况，尤其是在virtual/*命名空间中。您可以使用此变量来抑制 BitBake 的警告。

要使用该变量，请列出提供者名称（例如配方名称virtual/kernel等）。

哦
覆盖
BitBake 用于OVERRIDES控制在 BitBake 解析配方和配置文件后覆盖哪些变量。

以下是使用基于机器架构的覆盖列表的简单示例：

 覆盖 = "arm:x86:mips:powerpc"

您可以OVERRIDES在“条件语法（覆盖） ”部分找到有关如何使用的信息 。

磷
包
配方创建的包列表。

包_动态
承诺您的配方满足在其他配方中找到的可选模块的运行时依赖项。 PACKAGES_DYNAMIC 实际上并不满足依赖关系，它只是说明它们应该被满足。例如，如果RDEPENDS在构建期间通过PACKAGES_DYNAMIC 变量满足另一个包的硬性运行时依赖 ( ) ，但从未实际生成具有模块名称的包，那么另一个包将被破坏。

体育
食谱的时代。默认情况下，此变量未设置。当版本控制方案以某种向后不兼容的方式发生变化时，该变量用于使升级成为可能。

PERSISTENT_DIR
指定 BitBake 用于存储应在构建之间保留的数据的目录。特别是存储的数据是使用BitBake的持久化数据API的数据和PR Server和PR Service使用的数据。

PF
指定配方或包名称并包括所有版本和修订号（即eglibc-2.13-r20+svnr15508/和 bash-4.2-r1/）。

PN
配方名称。

公关
配方的修订。

PREFERRED_PROVIDER
确定当多个配方提供相同项目时应优先考虑哪个配方。您应该始终使用所提供项目的名称为变量添加后缀，并且您应该将其设置为 PN 要优先考虑的配方的 。一些例子：

 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
 PREFERRED_PROVIDER_virtual/libgl ?=“台面”

PREFERRED_PROVIDERS
确定在多个配方提供相同项目的情况下应优先考虑哪个配方。在功能上， PREFERRED_PROVIDERS与 PREFERRED_PROVIDER. 但是，该PREFERRED_PROVIDERS 变量允许您使用以下形式为多种情况定义首选项：

 PREFERRED_PROVIDERS = "xxx:yyy aaa:bbb ..."

此表格可方便地替换以下内容：

 PREFERRED_PROVIDER_xxx = "yyy"
 PREFERRED_PROVIDER_aaa = "bbb"

首选版本
如果有多个可用的配方版本，则此变量确定应优先考虑哪个配方。您必须始终为变量添加PN 要选择的后缀 ，并且应该相应地设置 PV 优先级。您可以使用 " %" 字符作为通配符来匹配任意数量的字符，这在指定包含可能会更改的长修订号的版本时非常有用。这里有两个例子：

 PREFERRED_VERSION_python = "2.7.3"
 PREFERRED_VERSION_linux-yocto = "3.10%"

前期
指定 BitBake 从中获取源代码的其他路径。当构建系统搜索源代码时，它首先尝试本地下载目录。如果该位置失败，构建系统会尝试由PREMIRRORS、上游源定义的位置，然后按MIRRORS 该顺序尝试由指定的位置 。

通常，您会为构建系统添加一个特定的服务器，通过在您的配置中添加如下内容，在其他任何服务器之前尝试：

 PREMIRRORS_prepend = "\
 git://.*/.* http://www.yoctoproject.org/sources/ \n \
 ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
 http://.*/.* http://www.yoctoproject.org/sources/ \n \
 https://.*/.* http://www.yoctoproject.org/sources/ \n"

这些更改会导致构建系统拦截 Git、FTP、HTTP 和 HTTPS 请求并将它们定向到http://源镜像。您也可以使用file://URL 指向本地目录或网络共享。

提供
可以知道特定配方的别名列表。默认情况下，配方自己的 PN 已隐式存在于其PROVIDES 列表中。如果配方使用PROVIDES，附加别名是配方的同义词，并且可以在构建期间满足其他配方的依赖关系，如由 指定 DEPENDS。

考虑PROVIDES来自配方文件的以下示例 语句libav_0.8.11.bb：

 提供 += "libpostproc"

该PROVIDES语句导致“libav”配方也称为“libpostproc”。

PRSERV_HOST
基于网络的 PR 服务主机和端口。

以下是如何设置PRSERV_HOST变量的示例：

 PRSERV_HOST = "本地主机:0"

如果要自动启动本地 PR 服务，则必须设置该变量。您可以设置PRSERV_HOST为其他值以使用远程 PR 服务。

光伏
食谱的版本。

电阻
重新依赖
列出必须安装的包的运行时依赖项（即其他包），以便构建的包正确运行。如果在构建过程中找不到此列表中的包，您将收到构建错误。

因为该RDEPENDS变量适用于正在构建的包，所以您应该始终以带有附加包名称的形式使用该变量。例如，假设您正在构建一个依赖于该perl包的开发包。在这种情况下，您将使用以下 RDEPENDS语句：

 RDEPENDS_${PN}-dev += "perl"

在示例中，开发包依赖于perl包。因此，RDEPENDS变量将 ${PN}-dev包名称作为变量的一部分。

BitBake 支持指定版本依赖。尽管语法因打包格式而异，但 BitBake 对您隐藏了这些差异。以下是使用RDEPENDS变量指定版本的一般语法：

 RDEPENDS_${PN} = " package( )"
                operator version

对于operator，您可以指定以下内容：

 =
 <
 >
 <=
 >=

例如，以下设置对版本 1.2 或更高版本的包的依赖foo：

 RDEPENDS_${PN} = "foo (>= 1.2)"

有关构建时依赖项的信息，请参阅 DEPENDS 变量。

提供
包还提供的包名称别名列表。这些别名对于在构建期间和在目标上（由 指定RDEPENDS）满足其他包的运行时依赖性非常有用 。

与所有包控制变量一样，您必须始终将变量与包名称覆盖结合使用。下面是一个例子：

 RPROVIDES_${PN} = "widget-abi-2"

重新推荐
扩展正在构建的包的可用性的包列表。正在构建的包不依赖于这个包列表来成功构建，但需要它们来扩展可用性。要指定包的运行时依赖项，请参阅 RDEPENDS 变量。

BitBake 支持指定版本推荐。尽管语法因打包格式而异，但 BitBake 对您隐藏了这些差异。以下是使用RRECOMMENDS变量指定版本的一般语法：

 RRCOMMENDS_${PN} = " package( )"
                operator version

对于operator，您可以指定以下内容：

 =
 <
 >
 <=
 >=

例如，以下设置对 1.2 版或更高版本的包的推荐foo：

 RRCOMMENDS_${PN} = "foo (>= 1.2)"

秒
部分
应在其中对包进行分类的部分。

src_URI
源文件列表 - 本地或远程。这个变量告诉 BitBake 为构建提取哪些位以及如何提取它们。例如，如果配方或附加文件需要从 Internet 获取单个 tarball，则配方或附加文件使用SRC_URI 指定该 tarball的条目。另一方面，如果配方或附加文件需要获取 tarball 并包含自定义文件，则配方或附加文件需要一个SRC_URI变量来指定所有这些源。

以下列表解释了可用的 URI 协议：

file://- 从本地机器获取文件，这些文件通常是元数据附带的文件。路径是相对于 FILESPATH 变量的。

bzr://-从 Bazaar 版本控制存储库中获取文件。

git://-从 Git 版本控制存储库中获取文件。

osc://-从 OSC（OpenSUSE 构建服务）版本控制存储库中获取文件。

repo://-从 repo (Git) 存储库中获取文件。

http://-使用 HTTP 从 Internet 获取文件。

https://-使用 HTTPS 从 Internet 获取文件。

ftp://-使用 FTP 从 Internet 获取文件。

cvs://-从 CVS 版本控制存储库中获取文件。

hg://-从 Mercurial (hg) 版本控制存储库中获取文件。

p4://-从 Perforce (p4) 版本控制存储库中获取文件。

ssh://-从安全外壳中获取文件。

svn://-从 Subversion (svn) 版本控制存储库中获取文件。

以下是一些值得一提的附加选项：

unpack-如果文件是存档，则控制是否解压文件。默认操作是解压缩文件。

subdir-将文件（或提取其内容）放入指定的子目录中。此选项对于不寻常的 tarball 或其他档案非常有用，这些档案在档案的子目录中没有其文件。

name-指定一个名称，SRC_URI当您在SRC_URI.

downloadfilename-指定存储下载文件时使用的文件名。

SRCDATE
用于构建包的源代码的日期。此变量仅适用于从源代码管理器 (SCM) 获取源的情况。

SRCREV
用于构建包的源代码的修订版。此变量仅在使用 Subversion、Git、Mercurial 和 Bazaar 时适用。如果你想构建一个固定的修订版本，并且你想避免每次 BitBake 解析你的配方时在远程存储库上执行查询，你应该指定SRCREV一个完整的修订标识符，而不仅仅是一个标签。

SRCREV_FORMAT
有助于构造有效的 SRCREV ，当多个源来控制的URL中使用的值 SRC_URI。

在这些情况下，系统需要帮助构建这些值。中的每个组件SRC_URI 都分配了一个名称，并在SRCREV_FORMAT变量中引用了这些名称。考虑一个带有名为“machine”和“meta”的 URL 的示例。在这种情况下，SRCREV_FORMAT可能看起来像“machine_meta”，并且这些名称会将 SCM 版本替换到每个位置。AUTOINC如果需要，仅添加一个占位符。并且，这个占位符被放置在返回字符串的开头。

邮票
指定用于创建配方标记文件的基本路径。实际图章文件的路径是通过评估此字符串然后附加其他信息来构建的。

清洁
指定用于创建配方标记文件的基本路径。与STAMP 变量不同 ，STAMPCLEAN可以包含通配符以匹配清理操作应删除的文件范围。BitBake 使用清理操作来删除在创建新图章时应该删除的任何其他图章。

总结
食谱的简短摘要，不超过 72 个字符。

SVNDIR
存储从 Subversion 系统检出的文件的目录。

吨
Ť
指向目录是 BitBake 在构建特定配方时放置临时文件，这些文件主要由任务日志和脚本组成。

TOPDIR
指向构建目录。BitBake 会自动设置这个变量。

A. Hello World 示例

目录

A.1. BitBake 你好世界
A.2. 获取BitBake
A.3. 设置 BitBake 环境
A.4. Hello World 示例

A.1. BitBake 你好世界

通常用于演示任何新编程语言或工具的最简单示例是“ Hello World ”示例。本附录以教程形式演示了 BitBake 上下文中的 Hello World。本教程描述了如何创建一个新项目以及允许 BitBake 构建它所需的适用元数据文件。

A.2. 获取BitBake

有关如何获取 BitBake 的信息，请参阅“获取 BitBake ”部分。一旦你的机器上有了源代码，BitBake 目录就会显示如下：

 $ ls -al
 共 100
 drwxrwxr-x。9 wmat wmat 4096 1 月 31 日 13:44。
 drwxrwxr-x。3 wmat wmat 4096 二月 4 日 10:45 ..
 -rw-rw-r--。1 wmat wmat 365 Nov 26 04:55 作者
 drwxrwxr-x。2 wmat wmat 4096 Nov 26 04:55 bin
 drwxrwxr-x。4 wmat wmat 4096 Jan 31 13:44 build
 -rw-rw-r--。1 wmat wmat 16501 Nov 26 04:55 ChangeLog
 drwxrwxr-x。2 wmat wmat 4096 十一月 26 日 04:55 班级
 drwxrwxr-x。2 wmat wmat 4096 十一月 26 日 04:55 conf
 drwxrwxr-x。3 wmat wmat 4096 十一月 26 日 04:55 贡献
 -rw-rw-r--。1 wmat wmat 17987 Nov 26 04:55 复制
 drwxrwxr-x。3 wmat wmat 4096 Nov 26 04:55 doc
 -rw-rw-r--。1 wmat wmat 69 Nov 26 04:55 .gitignore
 -rw-rw-r--。1 wmat wmat 849 Nov 26 04:55 HEADER
 drwxrwxr-x。5 wmat wmat 4096 Jan 31 13:44 lib
 -rw-rw-r--。1 wmat wmat 195 Nov 26 04:55 MANIFEST.in
 -rw-rw-r--。1 wmat wmat 2887 Nov 26 04:55 TODO

此时，您应该将 BitBake 克隆到与之前列表匹配的目录，但日期和用户名除外。

A.3. 设置 BitBake 环境

首先，您需要确保可以运行 BitBake。将您的工作目录设置为本地 BitBake 文件所在的位置并运行以下命令：

 $ ./bin/bitbake --version
 BitBake 构建工具核心版本 1.23.0，bitbake 版本 1.23.0

控制台输出会告诉您正在运行的版本。

运行 BitBake 的推荐方法来自您选择的目录。为了能够从任何目录运行 BitBake，您需要将可执行二进制文件添加到您的二进制文件到您的 shell 的环境 PATH变量中。首先，PATH通过输入以下内容查看当前变量：

 $回声 $PATH

接下来，将 BitBake 二进制文件的目录位置添加到 PATH. 这是一个将/home/scott-lenovo/bitbake/bin目录添加到PATH变量前面的示例 ：

 $ export PATH=/home/scott-lenovo/bitbake/bin:$PATH

您现在应该能够在bitbake 任何目录下工作时从命令行输入命令。

A.4. Hello World 示例

本练习的总体目标是利用任务和层概念构建一个完整的“Hello World”示例。因为这是 OpenEmbedded 和 Yocto Project 等现代项目利用 BitBake 的方式，所以该示例为理解 BitBake 提供了一个很好的起点。

为了帮助您了解如何使用 BitBake 构建目标，该示例bitbake 仅从命令开始，该命令会导致 BitBake 失败并报告问题。该示例通过向构建添加部分来推进，最终以一个有效的、最小的“Hello World”示例结束。

尽管已尽一切努力解释示例中发生的情况，但这些描述无法涵盖所有​​内容。您可以在本手册中找到更多信息。此外，您可以积极参与 有关 BitBake 构建工具的 http://lists.openembedded.org/mailman/listinfo/bitbake-devel讨论邮件列表。

笔记
这个例子受到以下来源的启发并大量借鉴：
邮件列表帖子 - BitBake 相当于“Hello, World！”

Hambedded Linux 博客文章 - 从 Bitbake Hello World 到图像

如前所述，此示例的目标是最终编译“Hello World”。但是，尚不清楚 BitBake 需要什么以及您必须提供什么才能实现该目标。回想一下，BitBake 使用了三种类型的元数据文件： 配置文件、 类和 食谱。但是他们去哪里呢？BitBake 如何找到它们？BitBake 的错误消息可帮助您回答这些类型的问题，并帮助您更好地准确了解正在发生的事情。

以下是完整的“Hello World”示例。

创建项目目录： 首先，为“Hello World”项目建立一个目录。以下是在主目录中执行此操作的方法：

 $ mkdir ~/hello
 $ cd ~/你好

这是 BitBake 将用来完成其所有工作的目录。您可以使用此目录来保存 BitBake 所需的所有元文件。拥有项目目录是隔离项目的好方法。

运行 Bitbake： 此时，您只有一个项目目录。运行bitbake命令，看看它做了什么：

 $bitbake
 未设置 BBPATH 变量且未设置 bitbake
 在预期位置找到一个 conf/bblayers.conf 文件。
 也许您不小心从错误的目录中调用了 bitbake？
 调试：从环境中删除了以下变量：
 GNOME_DESKTOP_SESSION_ID、XDG_CURRENT_DESKTOP、
 GNOME_KEYRING_CONTROL、DISPLAY、SSH_AGENT_PID、LANG、no_proxy、
 XDG_SESSION_PATH、XAUTHORITY、SESSION_MANAGER、SHLVL、
 MANDATORY_PATH、COMPIZ_CONFIG_PROFILE、WINDOWID、编辑器、
 GPG_AGENT_INFO、SSH_AUTH_SOCK、GDMSESSION、GNOME_KEYRING_PID、
 XDG_SEAT_PATH、XDG_CONFIG_DIRS、LESSOPEN、DBUS_SESSION_BUS_ADDRESS、
 _, XDG_SESSION_COOKIE, DESKTOP_SESSION, LESSCLOSE, DEFAULTS_PATH,
 UBUNTU_MENUPROXY、OLDPWD、XDG_DATA_DIRS、COLORTERM、LS_COLORS

此输出的大部分特定于与 BitBake 不直接相关的环境变量。但是，关于BBPATH变量和 conf/bblayers.conf文件的第一条消息 是相关的。

当您运行 BitBake 时，它​​开始寻找元数据文件。该 BBPATH 变量告诉 BitBake 在哪里查找这些文件。 BBPATH未设置，您需要设置它。如果没有BBPATH，Bitbake 根本找不到任何配置文件 ( .conf) 或配方文件 ( .bb)。BitBake 也找不到该bitbake.conf 文件。

设置BBPATH： 对于此示例，您可以BBPATH 按照PATH 附录中前面设置的相同方式进行设置。但是，您应该意识到，BBPATH在每个项目的配置文件中设置变量要灵活得多 。

在 shell 中，输入以下命令来设置和导出BBPATH变量：

 $BBPATH=" projectdirectory"
 $ 导出 BBPATH

在命令中使用您的实际项目目录。BitBake 使用该目录来查找项目所需的元数据。

笔记
指定项目目录时，请勿使用波浪号（“~”）字符，因为 BitBake 不会像 shell 那样扩展该字符。
运行 Bitbake： 既然你已经BBPATH定义好了，bitbake再次运行命令：

 $bitbake
 错误：回溯（最近一次通话）：
   文件“/home/scott-lenovo/bitbake/lib/bb/cookerdata.py”，第 163 行，包裹
     返回 func(fn, *args)
   文件“/home/scott-lenovo/bitbake/lib/bb/cookerdata.py”，第 173 行，在 parse_config_file 中
     返回 bb.parse.handle(fn, data, include)
   文件“/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py”，第 99 行，句柄
     返回 h['handle'](fn, data, include)
   文件“/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py”，第 120 行，在句柄中
     abs_fn = resolve_file(fn, 数据)
   文件“/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py”，第 117 行，在 resolve_file 中
     raise IOError("文件 %s 在 %s 中未找到" % (fn, bbpath))
 IOError: 在 /home/scott-lenovo/hello 中找不到文件 conf/bitbake.conf

 错误：无法解析 conf/bitbake.conf：在 /home/scott-lenovo/hello 中找不到文件 conf/bitbake.conf

此示例输出显示 BitBakeconf/bitbake.conf在项目目录中找不到该 文件。这个文件是 BitBake 为了构建目标必须找到的第一件事。而且，由于此示例的项目目录为空，因此您需要提供一个conf/bitbake.conf 文件。

创建conf/bitbake.conf： 在conf/bitbake.conf包括元数据和配方文件多个配置变量BitBake的用途。对于此示例，您需要在项目目录中创建文件并定义一些关键的 BitBake 变量。有关 的更多信息bitbake.conf，请参阅 https://web.archive.org/web/20150325165911/http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image /#an-overview-of-bitbakeconf

使用以下命令conf 在项目目录中创建目录：

 $ mkdir conf

从conf目录中，使用一些编辑器来创建bitbake.conf 它，以便它包含以下内容：

 TMPDIR = "${ TOPDIR }/tmp"
  CACHE    = "${TMPDIR}/cache"
  STAMP    = "${TMPDIR}/stamps"
  T        = "${TMPDIR}/work"
  B        = "${TMPDIR}"

该TMPDIR变量建立了一个 BitBake 用于构建输出和中间文件的目录（除了Setscene进程使用的缓存信息 。这里，该TMPDIR目录设置为 hello/tmp.

提示
您始终可以安全地删除该tmp 目录以重建 BitBake 目标。当您运行 BitBake 时，构建过程会为您创建目录。
有关此示例中定义的每个其他变量的信息，请单击链接以转到词汇表中的定义。

运行Bitbake： 确认conf/bitbake.conf 文件存在后，可以bitbake 再次运行命令：

$bitbake
错误：回溯（最近一次通话）：
文件“/home/scott-lenovo/bitbake/lib/bb/cookerdata.py”，第 163 行，包裹
返回 func(fn, *args)
文件“/home/scott-lenovo/bitbake/lib/bb/cookerdata.py”，第 177 行，在 _inherit 中
bb.parse.BBHandler.inherit(bbclass, “配置继承”, 0, 数据)
文件“/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py”，第 92 行，在继承中
包括（fn，文件，lineno，d，“继承”）
文件“/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py”，第 100 行，包含
raise ParseError(“不能 %(error_out)s 文件 %(fn)s” % vars(), oldfn, lineno)
ParseError: ParseError in configuration INHERITs: 无法继承文件 classes/base.bbclass

错误：无法解析基础：配置中的 ParseError INHERITs：无法继承文件 classes/base.bbclass

在示例输出中，BitBake 找不到该 classes/base.bbclass文件。接下来您需要创建该文件。

创建classes/base.bbclass： BitBake 使用类文件来提供通用代码和功能。BitBake 最低要求的类是 classes/base.bbclass文件。该base班是隐含的每一节继承。BitBakeclasses 在项目目录中查找类（即hello/classes 在本例中）。

创建classes目录如下：

 $ cd $HOME/你好
 $ mkdir 类

移动到classes目录，然后base.bbclass通过插入这一行来创建文件：

 添加任务构建

BitBake 运行的最小任务是 do_build任务。这是构建项目所需的全部示例。当然，base.bbclass根据 BitBake 支持的构建环境，可以有更多。有关该base.bbclass文件的更多信息，您可以查看 https://web.archive.org/web/20150325165911/http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to -an-image/#tasks。

运行Bitbake： 确认classes/base.bbclass 文件存在后，可以bitbake 再次运行命令：

 $bitbake
 没事做。使用“bitbake world”来构建一切，或者运行“bitbake --help”获取使用信息。

BitBake 终于没有报告任何错误。但是，您可以看到它确实没有任何关系。您需要创建一个配方，让 BitBake 有事可做。

创建一个层： 虽然对于这样一个小例子来说并不是真正必要的，但是创建一个层来使您的代码与 BitBake 使用的通用元数据分开是一个很好的做法。因此，此示例创建并使用了一个名为“mylayer”的层。

笔记
您可以在https://web.archive.org/web/20150325165911/http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-找到有关添加图层的更多信息 图像/#adding-an-example-layer。
至少，您的层中需要一个配方文件和一个层配置文件。配置文件需要conf 在层内的目录中。使用这些命令来设置层和conf 目录：

 $ cd $HOME
 $ mkdir mylayer
 $ cd mylayer
 $ mkdir conf

移动到conf目录并创建一个layer.conf具有以下内容的 文件：

 BBPATH .= ":${ LAYERDIR }"

 BBFILES += "${LAYERDIR}/*.bb"

 BBFILE_COLLECTIONS += "mylayer"
  BBFILE_PATTERN_mylayer := "^${LAYERDIR}/"

有关这些变量的信息，请单击链接以转到词汇表中的定义。

接下来您需要创建配方文件。在顶层的图层中，使用编辑器并创建一个名为的配方文件printhello.bb，该文件具有以下内容：

 描述= "打印 Hello World"
  PN = 'printhello'
  PV = '1'

 python do_build() {
    bb.plain("********************");
    bb.plain("* *");
    bb.plain("* 你好，世界！*");
    bb.plain("* *");
    bb.plain("********************");
 }

配方文件仅提供配方的描述、名称、版本和do_build 任务，并在控制台上打印出“Hello World”。有关这些变量的更多信息，请访问词汇表的链接。

使用目标运行 Bitbake： 现在 BitBake 目标存在，运行命令并提供该目标：

 $ cd $HOME/你好
 $ bitbake 打印你好
 错误：没有要构建的配方文件，请检查您的 BBPATH 和 BBFILES？

 摘要：显示 1 条错误消息，返回非零退出代码。

我们已经使用配方和层配置文件创建了层，但似乎 BitBake 仍然找不到配方。BitBake 需要conf/bblayers.conf列出项目层的 。没有这个文件，BitBake 无法找到配方。

创建conf/bblayers.conf： BitBake 使用该conf/bblayers.conf文件来定位项目所需的层。该文件必须驻留在conf项目目录中（即hello/conf对于本示例）。

将您的工作目录设置为该hello/conf 目录，然后创建bblayers.conf 文件，使其包含以下内容：

 BBLAYERS ?= " \
   /home/<你>/mylayer \
   ”

您需要you在文件中提供您自己的信息 。

使用目标运行 Bitbake： 现在您已经提供了bblayers.conf 文件，运行bitbake命令并提供目标：

 $ bitbake 打印你好
 解析配方：100% |######################################## ####################################|
 时间：00:00:00
 1 个 .bb 文件解析完成（0 个缓存，1 个解析）。1 个目标，0 个跳过，0 个屏蔽，0 个错误。
 注意：解决任何丢失的任务队列依赖项
 注意：准备运行队列
 注意：执行 RunQueue 任务
 ************************
 * *
 * 你好，世界！*
 * *
 ************************
 注意：任务摘要：尝试了 1 个任务，其中 0 个任务不需要重新运行并且都成功了。

BitBake 找到printhello配方并成功运行任务。

笔记
第一次执行后，再次重新运行 bitbake printhello不会导致打印相同控制台输出的 BitBake 运行。这样做的原因是printhello.bb配方的 do_build任务第一次 成功执行时，BitBake 会为该任务写入一个戳文件。因此，下次您尝试使用相同的bitbake命令运行任务时，BitBake 会注意到戳记，因此确定不需要重新运行任务。如果删除tmp目录或运行bitbake -c clean printhello 然后重新运行构建，“Hello, World!” 消息将再次打印。