注意

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

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

$ grep processor /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文件还可以包括其他使用includeorrequire 指令的配置文件。

在解析配置文件之前，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变量指定的其他类 。BitBakeclasses在BBPATH路径下的子目录中搜索类文件，方法与配置文件相同。

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

$ bitbake -e > mybb.log

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

fakeroot create_shar() {cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
usage()
{echo "test"######  The following "}" at the start of the line causes a parsing error ######
}
EOF
}Writing the recipe this way avoids the error:
fakeroot create_shar() {cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
usage()
{echo "test"###### The following "}" with a leading space at the start of the line avoids the error ######}
EOF
}

2.2定位和解析配方

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

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

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

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

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

PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}"
PV = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] or '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 = "upstream local"
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列表是通过配方的PN变量隐式创建的，并通过配方的PROVIDES 变量显式创建，该变量是可选的。

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

PROVIDES += "fullkeyboard"

的现状提供 这个食谱变成“键盘”，这是隐含的，“全键盘”，这是明确的名单。因此，keyboard_1.0.bb可以在两个不同的名称下找到 中的功能。

2.4偏好

的现状提供列表只搞清楚目标的食谱解决方案的一部分。由于目标可能有多个提供者，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。但是，如果您在.conf BitBake 解析的文件中定义以下变量，则可以更改该首选项：

PREFERRED_VERSION_a = "1.1"

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 使用此标志使某些任务特定于机器。

有关任务的更多信息，请参阅 任务部分。

2.7执行任务

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

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

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

• BB_调度器

• BB_SCHEDULERS

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

2.8校验和（签名）

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

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

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

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

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

PACKAGE_ARCHS[vardepsexclude] = "MACHINE"

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

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

PACKAGE_ARCHS[vardeps] = "MACHINE"

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

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

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

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

BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL \USER FILESPATH 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”，它会导致写出一组签名信息，STAMPS_DIR与指定的目标相对应。另一个当前可用的参数是“printdiff”，它使 BitBake 尝试建立它所能建立的最接近的签名匹配（例如在 sstate 缓存中），然后 bitbake-diffsigs遍历匹配以确定这两个标记树分歧的标记和增量。

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

2.9场景

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

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

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

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

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

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

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

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

2.10记录

除了用于控制执行时详细构建方式的标准命令行选项之外，bitbake 还支持通过BB_LOGCONFIG变量对Python 日志记录工具进行用户定义的配置。这个变量定义了一个 json 或 yaml日志配置 ，它将被智能地合并到默认配置中。使用以下规则合并日志记录配置：

• 如果顶级键bitbake_merge设置为 value ，则用户定义的配置将完全替换默认配置False。在这种情况下，所有其他规则都将被忽略。

• 用户配置必须具有version与默认配置的值匹配的顶级。

• handlers、formatters、 或 中定义的任何键filters都将合并到默认配置中的同一部分中，如果存在冲突，则用户指定的键将替换默认键。实际上，这意味着如果默认配置和用户配置都指定了一个名为 的处理程序myhandler，则用户定义的处理程序 将替换默认设置。为防止用户无意中替换默认处理程序、格式化程序或过滤器，所有默认处理程序均以“ BitBake.”前缀命名

• 如果记录器由用户定义，键bitbake_merge设置为False，则该记录器将被用户配置完全替换。在这种情况下，没有其他规则适用于该记录器。

• 给定记录器的所有用户定义filter和handlers属性将与默认记录器的相应属性合并。例如，如果用户配置增加了一个称为过滤器 myFilter的BitBake.SigGen，和默认配置增加了一个称为过滤器BitBake.defaultFilter，两个滤波器将被应用到记录器

例如，考虑以下用户日志记录配置文件，该文件将 VERBOSE 或更高级别的所有哈希等效相关消息记录到名为 hashequiv.log

{"version": 1,"handlers": {"autobuilderlog": {"class": "logging.FileHandler","formatter": "logfileFormatter","level": "DEBUG","filename": "hashequiv.log","mode": "w"}},"formatters": {"logfileFormatter": {"format": "%(name)s:%(levelname)s:%(message)s"}},"loggers": {"BitBake.SigGen.HashEquiv": {"level": "VERBOSE","handlers": ["autobuilderlog"]},"BitBake.RunQueue.HashEquiv": {"level": "VERBOSE","handlers": ["autobuilderlog"]}}
}