Bitbake中文手册--2(执行)

关注

原创最新推荐文章于 2026-06-16 14:44:26 发布 2.1k 阅读 AI 写同款· GEO 优化 ›

openembedded中的bitbake 在使用bitbake时出现了许多错误，结合openembedded的使用手册和bitbake的usr manual来梳理一下这个过程直接查看oe的中文手册，请查看： http://blog.chinaunix.net/uid-25909619-id-3767317.html省去源码git步骤，直接查看主要文件：OE使用6个目录来存放bitbake元数据 conf 目录用来保存bitbake. 阅读详情

https://www.yoctoproject.org/docs/3.1.2/bitbake-user-manual/bitbake-user-manual.html

bitbake中文手册

第2章执行

运行BitBake的主要目的是生成某种输出，例如单独的安装包，内核或软件开发工具包、或者甚至一个完整的特定于板的可引导Linux镜像，包含引导加载程序、内核和根文件系统。当然，您可以bitbake 命令选项，去执行单个任务、编译单个配方文件、捕获或者清除数据、或者简单地返回冠以执行环境的信息。

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

 $ bitbake <target>

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

注意

在执行BitBake之前，通过在项目的local.conf配置文件中设置BB_NUMBER_THREADS变量，来利用并行线程执行。根据编译主机决定这个值的通用方法就是执行下面的命令：

$ grep processor /proc/cpuinfo

该命令返回考虑超线程的处理器数量。因此，一个四核的编译超线程主机可能包含8个处理器，因此BB_NUMBER_THREADS的值应该设置为8。一些发行版本（例如Debian和Ubuntu）提供了ncpus（sudo apt install mdm）命令，这是一个更简单的解决方式；

2.1。解析基本配置元数据

BitBake做的第一件事是解析基本配置元数据。基本配置元数据包含bblayers.conf用于确定BitBake需要识别的哪些layer层的文件，所有必需的layer.conf文件（每层一个），以及bitbake.conf。数据本身有各种类型：

配方：有关特定软件的详细信息。
类数据：公共编译信息的抽象（例如，如何构建Linux内核）。
配置数据：特定于计算机的设置，策略决策等。配置数据充当将所有内容绑定在一起的粘合剂。

这些layer.conf文件用于构造关键变量，如BBPATH和BBFILES。BBPATH用于分别在conf/和class/目录下搜索配置和类文件。BBFILES用于查找配方文件（.bb和.bbappend）。如果没有bblayers.conf文件，那就假设用户在环境中直接设定了BBPATH和BBFILES。

接下来，bitbake.conf使用BBPATH刚刚构造的变量搜索文件。该bitbake.conf文件还可能包含使用include或require指令的其他配置文件。

在解析配置文件之前，Bitbake会查看某些变量，包括：（参考变量词汇表的解释）

BB_ENV_WHITELIST
BB_ENV_EXTRAWHITE
BB_PRESERVE_ENV
BB_ORIGENV
BITBAKE_UI

前四个变量涉及到Bitbake如何在任务执行期间处理shell环境变量，默认Bitbake会清理环境变量并提供，提供对shell执行环境的严格控制，但是，通过这四个变量的使用，你可以应用你的关于中允许bitbake使用的shell环境变量的控制，在执行任务期间；查看"传递信息到编译任务环境（3.6.3）"章节，在变量术语表中提供了关于这些变量如何工作和如何使用它们的更多信息。

基本配置元数据是全局的，因此会影响所有已执行的配方和任务。BitBake首先在当前工作目录中搜索可选conf/bblayers.conf配置文件。这个文件应该包含一个BBLAYERS变量，它是一个用空格分隔的“layer”目录列表。回想一下，如果BitBake的不能找到一个bblayers.conf 文件，那么它假设用户已经直接在环境中设置了BBPATH 和BBFILES变量。

对于此列表中的每个目录（层），conf/layer.conf会使用LAYERDIR变量设置这些layer层的目录并被解析，这个思想是这些文件为所提供的编译目录自动正确地构建BBPATH 和其他变量；

将conf/layer.conf 搜索并解析文件，并将 LAYERDIR 变量设置为找到该层的目录。这个想法是BBPATH 为给定的构建目录自动设置这些文件和其他变量。

然后，BitBake期望在用户指定的BBPATH中找到conf/ BitBake .conf文件。该配置文件通常包含用于导入其他元数据的指令，例如特定于体系结构、机器、本地环境等的文件。

在Bitbake的.conf文件中只允许变量的定义和指令的包含。一些变量直接影响BitBake的行为。这些变量可能是根据之前环境所使用到而配置的或在配置文件中设置的。“ 变量词汇表 ”一章提供了完整的变量列表。

在解析配置文件之后，BitBake使用其基本继承机制（通过类文件）来继承一些标准类。当遇到负责获取一个类的inherit指令时，BitBake会解析这个类。

base.bbclass文件始终被包含，其他在配置文件中使用INHERIT变量指定的类也会被包含。BitBake使用和配置文件相同的方法，在BBPATH路径下的classes子目录中搜索类文件。在执行环境中的一个获取配置文件和类文件的方法，是运行下面的Bitbake命令：

$ bitbake -e > mybb.log

通过查看mybb.log的顶部，可以看到执行环境中使用的一些配置文件和类文件。

注意

你需要知道BitBake如何解析花括号。如果配方在函数中使用右花括号并且字符没有前导空格，则BitBake会产生解析错误。如果在shell函数中使用一对花括号，则结束花括号不得位于行的开头而不带前导空格。这是一个导致BitBake产生解析错误的示例：

fakeroot create_shar() {
    cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
usage()
{
       echo "test"
       ###### 后面的“}”没有开头空格就会引起解析错误 ######
}

EOF
}

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

fakeroot create_shar() {
         cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
usage()
{
       echo "test"
       ######这个后面的“}”要有开头空格，在这行开始的地方来避免错误  ######
  }

EOF

}

2.2。定位和解析配方

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

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

BitBake解析使用BBFILES定位的每个配方和追加文件，并将各种变量的值存储到数据存储中(datastore)。

注意

附加文件按照它们在BBFILES中的顺序被应用。

对于每个文件，都会生成基本配置的新副本，然后逐行解析配方。任何继承语句都会导致BitBake查找并使用BBPATH 搜索路径解析类文件（.bbclass）。最后，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"

注意

layer层机制现在是复合代码的首选方法。虽然复合代码仍然存在，但其主要用途是设置层优先级并处理层之间的重叠（冲突）。

2.3。提供程序

假设已经指定BitBake执行目标并且已经解析了所有配方文件，BitBake开始计算出如何编译这个目标。BitBake会为每个配方查看PROVIDES表。PROVIDES表是被配方已知名字表。每一个配方的PROVIDES表的创建都是通过的配方的PN 变量隐式创建和配方的PROVIDES变量显式创建，这两个可选；

当配方使用PROVIDES变量时，recipe的功能可以在隐式PN名以外的其他名称下找到，例如假设配方的名字keyboard_1.0.bb 包含以下内容：

PROVIDES += "fullkeyboard"

那么这个配方的PROVIDES表就变成，”keyboard”是隐式的，而”fullkeyboard”是显式的，因此，在keyboard_1.0.bb内的功能可以在这两个名字下找到；

还有就是例如：

./poky/meta/recipes-extended/acpica/acpica_20190816.bb:44:PROVIDES = "iasl"
./poky/meta/recipes-extended/chkconfig/chkconfig-alternatives-native_1.3.59.bb:6:PROVIDES += "virtual/update-alternatives-native"
./poky/meta/recipes-extended/libtirpc/libtirpc_1.1.4.bb:10:PROVIDES = "virtual/librpc"
./poky/meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb:17:PROVIDES = "stress"
./meta-toradex-nxp/recipes-bsp/u-boot/u-boot-toradex-fw-utils_2019.07.bb:72:PROVIDES += "u-boot-fw-utils"
./meta-toradex-nxp/recipes-bsp/u-boot/u-boot.inc:2:PROVIDES = "virtual/bootloader"
./meta-toradex-nxp/recipes-bsp/u-boot/u-boot-toradex_2019.07.bb:5:PROVIDES += "u-boot"
./meta-toradex-nxp/recipes-bsp/u-boot/u-boot-toradex-fw-utils_2018.03.bb:47:PROVIDES += "u-boot-fw-utils"
./meta-toradex-nxp/recipes-bsp/u-boot/u-boot-toradex_2018.03.bb:7:PROVIDES += "u-boot"

等等

2.4。首选项（优先级）

PROVIDES 表只是为了检算出目标配方的方法的一部分，因为目标可能有多个提供程序，BitBake需要通过确定提供程序的首选项(首选等级)来对提供程序进行优先排序。一个具有多个提供程序的目标的常见例子是“virtual/kernel”，它在每个内核recipe配方的PROVIDES列表中。每台机器通常通过在机器配置文件中使用类似以下的一行来选择最好的内核提供程序:

PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"

默认的PREFERRED_PROVIDER是与目标同名的提供程序。BitBake迭代和解析每一个需要编译的目标，和在这个过程中处理他们的依赖；由于给定提供程序可能存在多个版本，因此理解如何选择提供程序变得很复杂；BitBake默认是选择最高版本的提供程序，版本比较使用与Debian相同的方法，可以使用 PREFERRED_VERSION 变量指定特殊的版本，可以通过使用DEFAULT_PREFERENCE变量来影响顺序；默认情况下，文件优先级为“0”，把配方的DEFAULT_PREFERENCE 设置为“-1”，这个配方将不会被使用，除非明确引用，设置为“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解析后，将会改变这个优先级，选择1.1。

PREFERRED_VERSION_a = "1.1"

注意

配方通常会提供两个版本——稳定的、编号的(和优选的)版本，以及自动从源代码仓库库检出（check out）的版本，后者被认为是更“前沿”的，但只能显式地选择。例如，在OpenEmbedded代码库中，BusyBox有一个标准的、版本化的配方文件busybox_1.22.1，但是也有一个基于git的版本busybox_git.bb，显式的包含下面一行

 DEFAULT_PREFERENCE = "-1"

去确保稳定编号的版本会被首选，除非开发者选择其他的；

总之，BitBake为每个目标创建了一个优先级最高的提供程序列表。

2.5。依赖

每个目标的Bitbake编译都是由多个任务组成的，例如获取(fetch)、解压(unpack)、补丁(patch)、配置(configure)、和编译(compile);为了在多核系统上获得最佳性能，BitBake将每个任务视为具有自己的一组依赖的独立实体。

依赖关系是通过几个变量定义的。您可以在本手册末尾附近的变量词汇(Bitbake中文手册--5(词汇))找到有关BitBake使用的变量信息。在基本级别上，知道BitBake 所使用DEPENDS和RDEPENDS变量就足够了，在计算依赖关系时。有关BitBake如何处理依赖关系的更多信息，请参阅“ 依赖3.10章节 ”部分。

2.6。任务列表

根据生成的提供程序列表和依赖关系信息，BitBake现在可以准确计算出哪些任务需要执行以及什么样的顺序执行。“ 执行任务2.7章节 ”部分提供了有关BitBake如何选择下一个要执行的任务的更多信息。

现在，BitBake编译开始，并根据变量BB_NUMBER_THREADS 设置的线程数值限制，将任务分配到现成中执行。只要有任务准备好运行，BitBake就会继续分配线程，这些任务已经满足所有依赖关系，并且未超过线程阈值。值得注意的是，通过正确设置BB_NUMBER_THREADS变量，可以大大加快编译时间。

每个任务完成后，时间戳将写入被STAMP变量指定的目录。随后的运行中，BitBake在tmp/stamps中查找编译目录，并且不会重新运行已经完成的任务，除非发现一个无效的时间戳。目前，无效的时间戳只在每个基础配方中存在，因此例如，如果配置戳内的时间戳大于给定目标的编译时间戳，那么编译任务将重新运行。然而，再次运行compile任务对依赖于该目标的其他提供程序没有影响。

戳记的精确格式时部分可配置的，在BitBake的现代版本中，将哈希附加到戳记，这样如果配置更改，戳记将失效，任务将自动重新运行。此哈希或使用的签名由配可配置的签名策略管理（有关信息，请参阅“ 校验和（签名）2.8章节 ”部分）。还可以使用“stamp-extra-info”任务标志将额外的元数据附加到戳记。例如，OpenEmbedded使用此标志使某些任务机器特定化。

注意

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

2.7。执行任务

任务可以是shell任务或Python任务。对于shell任务，BitBake将写一个shell脚本到${T}/run.do_taskname.pid ，然后执行这个脚本。生成的shell脚本包含所有导出的变量，以及展开所有变量的shell函数,shell脚本的输出会被写到 ${T}/log.do_taskname.pid文件，

将shell脚本写入然后执行脚本。生成的shell脚本包含所有导出的变量，shell函数扩展了所有变量。shell脚本的输出转到该文件。查看运行文件中的扩展shell函数和日志文件中的输出是一种有用的调试技术。 ${T}/run.do_taskname.pid${T}/log.do_taskname.pid，在运行文件中查找扩展的shell函数和在log文件中查找输出，是一个很有用的调试技术；

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

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

BB_SCHEDULER
BB_SCHEDULERS

可以在任务的主函数之前和之后运行其他函数。可以使用“prefuncs”和“postfuncs”标志在任务中列出函数，来实现上面的操作。

2.8。校验（签名）

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

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

另一个问题来自包含可能被调用也可能不被调用的函数的“run”脚本。增量编译解决方案包含用于确定shell函数之间的依赖关系的代码此代码用于将“run”脚本精简到最小集，从而缓解了这个问题，并使“run”脚本更具可读性。

到目前为止，我们有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 TERM \
         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尝试建立最接近的签名匹配(例如在状态缓存中)，然后在匹配上运行BitBake -diffsigs，以确定这两个戳记树的不同点和delta。

注意

未来版本的BitBake可能会通过其他“-S”参数触发其他签名处理程序。

您可以在“ 任务校验和和设置3.12章节 ”部分中找到有关校验元数据的更多信息。

2.9。Setscene

setscene进程使BitBake能够处理“预编译”的部件。处理和重新使用这些部件的能力使BitBake无需每次都从头开始编译一些东西。相反，BitBake可以在可能的情况下使用现有的编译部件。

BitBake需要具有可靠的数据，指示部件是否兼容。上一节中描述的签名提供了表示部件是否兼容的理想方式。如果签名相同，则可以重用此对象。如果一个对象可以被可以重新使用，那么问题就变成了如何用预先编译的部件替换给定的任务或任务集。BitBake通过“setscene”过程解决了这个问题。

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

BitBake首先调用由BB_HASHCHECK_FUNCTION 变量定义的函数，其中包含要创建的任务列表和相应的哈希值。该函数被设计为快速的，并可以返回它认为可以获得部件的任务列表。接下来，对于作为可能性返回的每个任务，BitBake执行可能的涵盖这个部件所的任务的一个setscene版本。Setscene版本的任务将字符串“_setscene”附加到任务名称。因此，例如，具有名称为xxx的任务就会有一个名为具有名为xxx_setscene的setscene任务。该任务的setscene版本执行并提供返回成功或失败的必要部件。

如前所述，部件(artifact)可以涵盖多个任务。例如，如果已经有编译的二进制文件，那么获取编译器是没有意义的。为了解决这个问题，BitBake为每个成功的setscene任务调用 BB_SETSCENE_DEPVALID 函数，以了解它是否需要获取该任务的依赖关系。

最后，在执行了所有的setscene任务之后，BitBake调用BB_SETSCENE_VERIFY_FUNCTION2列举的函数，认为已被“cover”的任务列表中列出的函数。然后，元数据可以确保此列表是正确的，并且可以通知BitBake它希望运行的指定任务而不管setscene结果如何。

您可以在“ 任务校验和设置3.12章节”部分中找到有关setscene元数据的更多信息。

2.10。日志

除了标准的命令行选项来控制执行时编译的详细程度外，bitbake还通过BB_LOGCONFIG变量支持用户定义的Python日志( Python logging )功能配置。这个变量定义了一个json或者yaml的日志配置（ logging configuration ）,会智能的融合(merge)到默认配置中；日志配置融合(merge)是按照下面的规则:

如果顶层关键字 bitbake_merge设置为False，用户定义配置会完全替换调默认配置，这种情况下无视其他规则；
用户配置必须有一个顶层版本，这个版本必须匹配默认配置的版本；
在处理程序、格式化程序或过滤器器中定义的任何键都将合并到默认配置的相同部分中，如果存在冲突，用户指定的键将替换默认键；实际上，这意味着如果默认配置和用户配置都指定了名为myhandler的处理程序，则用户定义的处理程序将替换默认配置，为了防止用户无意中替换默认的处理程序、格式化程序或过滤器，所有的默认处理程序都以“BitBake”前缀命名。
如果用户把键bitbake_merge设置为False而定义一个日志器(logger)，则该日志器(logger)将被用户配置完全替换。在这种情况下，没有其他规则适用于该记录器；
用户为给定日志器(logger)定义的所有过滤器和处理器属性将与默认日志器(logger)的相应属性合并(merge),例如如果用户配置增加了一个名为myFilter的过滤器到BitBake.SigGen，而默认配置增加了一个名为BitBake.defaultFilter的过滤器，那么这两个过滤器都会被应用到日志器(logger)；

下面一个例子，考虑以下用户日志配置文件，该文件将所有与 Hash Equivalence 相关的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"]
            }
        }
    }