suvine

BitBake User Manual（译）

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。例子

2.执行

2.1。解析基本配置元数据

2.2。定位和解析食谱

2.3。偏好和提供者

2.4。依赖

2.5。任务列表

2.6。执行任务

2.7。校验和（签名）

2.8。Setscene

3.语法和运算符

3.1。基本语法

3.1.1。基本变量设置

3.1.2。可变扩展

3.1.3。设置默认值（？=）

3.1.4。设置弱默认值（?? =）

3.1.5。立即变量扩展（：=）

3.1.6。使用Spaces追加（+ =）和前置（= +）

3.1.7。在没有空格的情况下追加（。=）和前置（=。）

3.1.8。追加和前置（覆盖样式语法）

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。Shell函数

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。任务校验和和Setscene

4.文件下载支持

4.1。下载（取指）

4.2。解包

4.3。取程序

4.3.1。本地文件提取器（file://）

4.3.2。CVS fetcher（(cvs://）

4.3.3。HTTP / FTP wget的提取器（http://，ftp://，https://）

4.3.4。Subversion（SVN）Fetcher（svn://）

4.3.5。GIT Fetcher（git://）

4.3.6。其他Fetchers

4.4。自动修订

5.变量词汇表

词汇表

A. Hello World示例

A.1。BitBake Hello World

A2。获得BitBake

A.3。设置BitBake环境

A.4。Hello World示例

第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的系统，例如Yocto Project和OpenEmbedded，信息尝试尽可能独立。在某些情况下，在手册中使用构建系统上下文中的场景或示例来帮助理解。对于这些情况，手册清楚地说明了背景。

1.1。介绍

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

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

BitBake根据提供的构建任务的元数据执行任务。元数据存储在recipe（.bb），configuration（.conf）和class（.bbclass）文件中，并为BitBake提供有关要运行的任务以及这些任务之间的依赖关系的说明。
BitBake包括一个fetcher库，用于从源控制系统或网站等各种位置获取源代码。
要构建的每个单元的指令（例如一个软件）称为配方文件，包含有关单元的所有信息（依赖项，源文件位置，校验和，描述等）。
BitBake包括客户端/服务器抽象，可以从命令行使用或作为XMLRPC上的服务使用，并具有多个不同的用户界面。

1.2。历史和目标

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

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

今天，BitBake是OpenEmbedded 项目的主要基础，该项目用于构建和维护诸如Angstrom Distribution之类的Linux发行版，并用作Linux项目（如Yocto项目）的构建工具。

在BitBake之前，没有任何其他构建工具能够充分满足有抱负的嵌入式Linux发行版的需求。传统桌面Linux发行版使用的所有构建系统都缺乏重要的功能，并且在嵌入式领域中普遍存在的基于Buildroot的临时系统都不具备可扩展性或可维护性。

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

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

随着时间的推移，显然需要一些进一步的要求：

处理基本配方的变体（例如native，sdk和multilib）。
将元数据拆分为图层并允许图层相互覆盖。
允许将给定的一组输入变量表示为任务作为校验和。基于该校验和，允许使用预构建组件加速构建。

BitBake满足所有原始要求以及更多功能，并对基本功能进行了扩展，以反映其他要求。灵活性和力量始终是优先事项。BitBake具有高度可扩展性，支持嵌入式Python代码和任意任务的执行。

1.3。概念

BitBake是一个用Python语言编写的程序。在最高级别，BitBake解释元数据，决定运行所需的任务，并执行这些任务。与GNU Make类似，BitBake控制着软件的构建方式。GNU Make通过“makefile”实现其控制。BitBake使用“食谱”。

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

本节的其余部分介绍了应该理解的几个概念，以便更好地利用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.bbclass是特别的，因为它总是自动包含在所有食谱和类中。此类包含标准基本任务的定义，例如提取，解包，配置（默认为空），编译（运行任何Makefile），安装（默认为空）和打包（默认为空）。这些任务经常被项目开发过程中添加的其他类覆盖或扩展。

1.3.4。图层

图层允许您将不同类型的自定义设置相互隔离。虽然您可能会发现在处理单个项目时将所有内容保留在一个层中很有诱惑力，但组织元数据越模块化，就越容易应对未来的更改。

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

1.3.5。附加文件

附加文件，即具有.bbappend文件扩展名的文件，将构建信息添加或扩展到现有配方文件。

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

附加文件中的信息将覆盖类似命名的配方文件中的信息。

命名追加文件时，可以使用通配符（％）来匹配配方名称。例如，假设您有一个名为如下的追加文件：

     busybox_1.21％。bbappend

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

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

如果busybox配方更新为 busybox_1.3.0.bb，则追加名称将不匹配。但是，如果您命名了追加文件 busybox_1.%.bbappend，那么您将获得匹配。

1.4。获得BitBake

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

克隆BitBake： 使用Git克隆BitBake源代码库是获取BitBake的推荐方法。克隆存储库可以轻松修复错误并访问稳定的分支和主分支。一旦克隆了BitBake，就应该使用最新的稳定分支进行开发，因为master分支用于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。

1.5。BitBake命令

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

1.5.1。用法和语法

以下是BitBake的用法和语法：

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

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

     选项：
       --version显示程序的版本号并退出
       -h， -  help显示此帮助消息并退出
       -b BUILDFILE， -  buildfile = BUILDFILE
                             直接从特定的.bb配方执行任务。
                             警告：不处理来自其他的依赖项
                             食谱。
       -k， - 继续在出错后尽可能继续。虽然
                             失败的目标和任何依赖它的东西都不能
                             建造之前，尽可能建造
                             停止。
       -a， -  strianttconfigs尝试使用替代方法继续构建
                             供应商尽可能。
       -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， -  posttread = POSTFILE
                             在bitbake.conf之后读取指定的文件。
       -v， -  verbose将更多日志消息数据输出到终端。
       -D， -  debug增加调试级别。您可以指定更多
                             不止一次。
       -n， -  dr-run不执行，只是通过动作。
       -S DUMP_SIGNATURES， -  dump-signatures = DUMP_SIGNATURES
                             转储签名构造信息，用
                             没有任务执行。参数传递给
                             签名处理代码，如果没有特定的话，使用'none'
                             处理程序是必需的
       -p， -  only-only解析BB配方后退出。
       -s， -  show-versions显示所有配方的当前和首选版本。
       -e， -  environment显示完整的全局或每个包环境
                             有关变量所在的信息
                             设置/改变。
       -g， -  chartviz保存指定的依赖关系树信息
                             点语法中的目标。
       -I EXTRA_ASSUME_PROVIDED， -  signore-deps = EXTRA_ASSUME_PROVIDED
                             假设这些依赖关系不存在且已经存在
                             提供（相当于ASSUME_PROVIDED）。有用的
                             使依赖图更具吸引力
       -l DEBUG_DOMAINS， -  log-domains = DEBUG_DOMAINS
                             显示指定日志记录域的调试日志记录
       -P， -  profile查询命令并保存报告。
       -u UI， -  ui = UI要使用的用户界面（例如knotty，hob，depexp）。
       -t SERVERTYPE， -  password = SERVERTYPE
                             选择要使用的服务器，进程或xmlrpc。
       --revisions-changed根据是否上游设置退出代码
                             浮动修订已经改变或没改变。
       --server-only运行没有UI的bitbake，只启动服务器
                             （炊具）过程。
       -B BIND， -  bind = BIND要绑定的bitbake服务器的名称/地址。
       --no-setscene不要运行任何setscene任务。sstate将被忽略
                             一切都需要，建成。
       --remote服务器= remote_server的
                             连接到指定的服务器。
       -m， -  kill-server终止远程服务器。
       --observe-only作为仅观察客户端连接到服务器。
       --status-only检查远程bitbake服务器的状态。

1.5.2。例子

本节介绍一些显示如何使用BitBake的示例。

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

执行单个配方文件的任务相对简单。您指定有问题的文件，BitBake解析它并执行指定的任务。如果您没有指定任务，BitBake将执行默认任务，即“build”.BitBake在执行此操作时遵循任务间依赖性。

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

     $ bitbake -b foo_1.0.bb

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

     $ bitbake -b foo.bb -c clean

注意

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

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

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

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

     $ bitbake foo

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

     $ bitbake -c clean foo

1.5.2.3。生成依赖关系图

BitBake能够使用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 virtual / kernel -I eglibc foo

第2章执行

2.1。解析基本配置元数据

2.2。定位和解析食谱

2.3。偏好和提供者

2.4。依赖

2.5。任务列表

2.6。执行任务

2.7。校验和（签名）

2.8。Setscene

运行BitBake的主要目的是生成某种输出，例如图像，内核或软件开发工具包。当然，您可以执行bitbake 命令，其中包含使其执行单个任务，编译单个配方文件，捕获或清除数据或仅返回有关执行环境的信息的选项。

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

     $ bitbake

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

注意

在执行BitBake之前，您应该通过BB_NUMBER_THREADS 在local.conf 配置文件中设置变量来利用并行线程执行。

2.1。解析基本配置元数据

BitBake做的第一件事是解析基本配置元数据。基本配置元数据包含bblayers.conf用于确定BitBake需要识别哪些层的文件，所有必需的 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_PRESERVE_ENV
BB_ENV_EXTRAWHITE
BITBAKE_UI

您可以在“将信息传递到构建任务环境 ”部分中找到有关如何将环境变量传递到BitBake执行环境的信息。

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

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

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

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

文件中只允许使用变量定义和include指令.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
     用法（）
     {
       回声“测试”
       ######行开头的以下“}”导致解析错误######
     }
     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：

     PV =“$ {@ bb.parse.BBHandler.vars_from_file（d.getVar（'FILE'），d）[1]或'1.0'}”
     PN =“$ {@ bb.parse.BBHandler.vars_from_file（d.getVar（'FILE'），d）[0]或'defaultpkgname'}”

在此示例中，名为“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配方的默认值是其名称（PN），但是，配方可以提供多种功能。

作为添加额外提供程序的示例，假设命名的配方 foo_1.0.bb包含以下内容：

     PROVIDES + =“virtual / bar_1.0”

配方现在提供“foo_1.0”和“virtual / bar_1.0”。“虚拟/”命名空间通常用于表示期望多个提供者并且用户在它们之间进行选择的情况。内核和工具链组件是OpenEmbedded中的常见情况。

有时目标可能有多个提供者。一个常见的例子是“虚拟/内核”，它由每个内核配方提供。每台机器通常使用与机器配置文件中类似的行来选择最佳内核提供程序：

     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”

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

2.4。依赖

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

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

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

2.5。任务列表

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

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

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

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

邮票的确切格式是部分可配置的。在BitBake的现代版本中，散列附加到标记，以便在配置更改时，标记变为无效并且任务会自动重新运行。此哈希或使用的签名由配置的签名策略控制（有关信息，请参阅“ 校验和（签名） ”部分）。还可以使用“stamp-extra-info”任务标志将额外的元数据附加到戳记。例如，OpenEmbedded使用此标志使某些任务特定于机器。

注意

某些任务被标记为“nostamp”任务。运行这些任务时，不会创建时间戳文件。因此，“nostamp”任务总是重新运行。

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

2.6。执行任务

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

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

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

BB_SCHEDULER
BB_SCHEDULERS

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

2.7。校验和（签名）

校验和是任务输入的唯一签名。任务的签名可用于确定是否需要运行任务。因为触发任务的任务输入发生变化，所以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 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-：配方中每个任务的基本哈希值。
BB_BASEHASH_：每个依赖任务的基本哈希值。
BBHASHDEPS_：每个任务的任务依赖性。
BB_TASKHASH：当前正在运行的任务的哈希值。

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

注意

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

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

2.8。Setscene

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

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

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

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

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

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

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

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

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

第3章语法和运算符

3.1。基本语法

3.1.1。基本变量设置

3.1.2。可变扩展

3.1.3。设置默认值（？=）

3.1.4。设置弱默认值（?? =）

3.1.5。立即变量扩展（：=）

3.1.6。使用Spaces追加（+ =）和前置（= +）

3.1.7。在没有空格的情况下追加（。=）和前置（=。）

3.1.8。追加和前置（覆盖样式语法）

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。Shell函数

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。任务校验和和Setscene

Bitbake文件有自己的语法。语法与其他几种语言有相似之处，但也有一些独特的功能。本节介绍可用的语法和运算符，并提供示例。

3.1。基本语法

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

3.1.1。基本变量设置

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

     VARIABLE =“value”

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

     VARIABLE =“value”
     VARIABLE =“value”

设置VARIABLE为“”将其设置为空字符串，而将变量设置为“”将其设置为空白区域（即这些值不是相同的值）。

     VARIABLE =“”
     VARIABLE =“”

3.1.2。可变扩展

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

     A =“aval”
     B =“前$ {A}帖子”

您应该意识到，只要B引用，其评估将取决于当时的状态 A。因此，B在先前示例中的后续评估可能导致取决于值的不同值A。

3.1.3。设置默认值（？=）

您可以使用“？=”运算符来为变量实现“更柔和”的赋值。这种类型的赋值允许您在解析语句时定义变量（如果未定义），但如果变量具有值，则保留值。这是一个例子：

     A？=“aval”

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

注意

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

3.1.4。设置弱默认值（?? =）

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

     A ?? =“somevalue”
     A ?? =“其他值”

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

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

3.1.5。立即变量扩展（：=）

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

     T =“123”
     答：=“$ {B} $ {A}测试$ {T}”
     T =“456”
     B =“$ {T} bval”
     C =“cval”
     C：=“$ {C}追加”

在此示例中，A包含“test 123”，因为${B}并且 ${A}在解析时未定义，这留下“test 123”。并且，变量C 包含“cvalappend”，因为${C}立即扩展为“cval”。

3.1.6。使用Spaces追加（+ =）和前置（= +）

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

     B =“bval”
     B + =“additionaldata”
     C =“cval”
     C = +“测试”

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

3.1.7。在没有空格的情况下追加（。=）和前置（=。）

如果要在没有插入空格的情况下追加或前置值，请使用“。=”和“=”。运营商。这里有些例子：

     B =“bval”
     B。=“additionaldata”
     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 data”。

注意

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

运算符“_append”和“_prepend”与运算符“。=”和“=”不同。因为它们被推迟到解析完成之后而不是立即应用。

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标志为“abc456”。

3.1.11。内联Python变量扩展

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

     DATE =“$ {@ time.strftime（'％Y％m％d'，time.gmtime（））}”

此示例导致DATE 变量成为当前日期。

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”特定版本而不是非条件版本。这是一个例子：
```
     OVERRIDES =“架构：os：机器”
     TEST =“默认”
     TEST_os =“osspecific”
     TEST_nooverride =“othercondvalue”
                        
```
在此示例中，OVERRIDES 变量列出了三个覆盖：“architecture”，“os”和“machine”。变量TEST本身具有默认值“default”。TEST 通过将“os”覆盖附加到变量（即TEST_os）来选择变量的特定于os的版本。
追加和前置： BitBake还支持根据是否列出特定项目对变量值进行附加和前置操作OVERRIDES。这是一个例子：
```
     DEPENDS =“glibc ncurses”
     OVERRIDES =“机器：本地”
     DEPENDS_append_machine =“libmad”
                        
```
在这个例子中，DEPENDS变成“glibc ncurses libmad”。

3.2.2。重点扩展

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

     A $ {B} =“X”
     B =“2”
     A2 =“Y”

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

3.2.3。例子

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

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

     OVERRIDES =“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。

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

     OVERRIDES =“foo”
     A =“Z”
     A_append_foo =“X”

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

下一个示例按照第一个示例中的顺序反转了追加和覆盖：

     OVERRIDES =“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 变量来定位所需的包含和类文件。该BBPATH变量类似于环境变量PATH。

为了使BitBake能够找到包含和类文件，它们需要位于可以找到的“classes”子目录中BBPATH。

3.3.2。 `inherit`指示

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

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

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

     继承autotools

在这种情况下，BitBake的将搜索的目录 classes/autotools.bbclass 在BBPATH。

注意

您可以在“inherit”语句之后覆盖配方中的继承类的任何值和函数。

3.3.3。 `include`指示

BitBake了解该include 指令。该指令使BitBake解析您指定的任何文件，并在该位置插入该文件。该指令很像Make中的等效指令，除非如果在include行上指定的路径是相对路径，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从配置文件调用的类文件，如下所示：

     INHERIT + =“abc”

此配置指令导致在解析期间在指令的点处继承命名类。与该inherit指令一样，该 .bbclass文件必须位于其中一个目录中的“classes”子目录中BBPATH。

注意

因为.conf在BitBake执行期间首先解析文件，所以使用 INHERIT继承类有效地继承全局类（即所有配方）。

3.4。功能

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

Shell函数： 用shell脚本编写的函数，可直接作为函数，任务或两者执行。它们也可以被其他shell函数调用。
BitBake样式Python函数： 用Python编写并由BitBake或其他Python函数执行的函数bb.build.exec_func()。
Python函数： 用Python编写并由Python执行的函数。
匿名Python函数： 在解析过程中自动执行Python函数。

无论函数类型如何，您只能在class（.bbclass）和recipe（.bb或.inc）文件中定义它们。

3.4.1。Shell函数

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

     some_function（）{
         回声“你好世界”
     }

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

3.4.2。BitBake样式Python函数

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

BitBake函数的一个示例是：

     python some_python_function（）{
         d.setVar（“TEXT”，“Hello World”）
         print d.getVar（“TEXT”，True）
     }

由于已经导入了Python“bb”和“os”模块，因此您无需导入这些模块。此外，在这些类型的函数中，数据存储区（“d”）是一个全局变量，并且始终可自动使用。

3.4.3。Python函数

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

     def get_depends（d）：
         如果d.getVar（'SOMECONDITION'，True）：
             返回“dependencywithcond”
         其他：
             返回“依赖”
     SOMECONDITION =“1”
     DEPENDS =“$ {@ get_depends（d）}”

这将导致DEPENDS 包含dependencywithcond。

以下是有关Python函数的一些知识：

Python函数可以使用参数。
BitBake数据存储区不会自动可用。因此，您必须将其作为参数传递给函数。
“bb”和“os”Python模块可自动使用。您无需导入它们。

3.4.4。匿名Python函数

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

     python __anonymous（）{
         如果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 提供了一种机制，使函数的配方版本能够调用函数的原始版本。

要使用此技术，您需要具备以下条件：

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

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

     EXPORT_FUNCTIONS

例如，继续使用相同的示例，其中的语句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）和class（.bbclass）文件中支持任务。按照惯例，任务名称以字符串“do_”开头。

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

     python do_printdate（）{
         进口时间
         print time.strftime（'％Y％m％d'，time.gmtime（））
     }
     在do_build之前的do_fetch之后添加addtask printdate

3.5.1。将功能提升为任务

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

     python do_printdate（）{
         进口时间
         print time.strftime（'％Y％m％d'，time.gmtime（））
     }
     在do_build之前的do_fetch之后添加addtask printdate

在该示例中，定义函数，然后将其作为任务提升。该do_printdate任务将成为的依赖do_build任务，这是默认的任务。而且，do_printdate任务取决于do_fetch任务。执行do_build任务会导致do_printdate任务首先运行。

3.5.2。删除任务

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

     deltask printdate

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

在运行任务时，BitBake严格控制构建任务的执行环境，以确保构建机器中的不受污染不会影响构建。因此，如果您确实希望将某些内容传递到构建任务环境，则必须执行以下两个步骤：

告诉BitBake将您想要的环境加载到数据存储区中。您可以通过BB_ENV_EXTRAWHITE 变量完成此操作。例如，假设您要阻止构建系统访问您的$HOME/.ccache 目录。以下命令告诉BitBake CCACHE_DIR从环境加载到数据存储区：
```
     导出BB_ENV_EXTRAWHITE =“$ BB_ENV_EXTRAWHITE CCACHE_DIR”
                        
```
告诉BitBake将您加载到数据存储区的内容导出到每个正在运行的任务的任务环境中。将环境中的内容加载到数据存储区（上一步）仅使其在数据存储区中可用。要将其导出到每个正在运行的任务的任务环境，请在本地配置文件local.conf或分发配置文件中使用与以下内容类似的命令：
```
     导出CCACHE_DIR
                        
```
注意
前面步骤的副作用是BitBake将变量记录为构建过程的依赖关系，例如setscene校验和。如果这样做会导致不必要的任务重建，则可以将变量列入白名单，以便setscene代码在创建校验和时忽略依赖关系。

有时，能够从原始执行环境获取信息是有用的。Bitbake将原始环境的副本保存到名为的特殊变量中 BB_ORIGENV。

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

     BB_ORIGENV  - 添加例子？

     origenv = d.getVar（“BB_ORIGENV”，False）
     bar = origenv.getVar（“BAR”，False）

上一个示例BAR从原始执行环境返回。

默认情况下，BitBake会清除环境以仅包含在其白名单中导出或列出的内容，以确保构建环境具有可重现性和一致性。

3.6。可变标志

变量标志（varflags）有助于控制任务的功能和依赖性。BitBake使用以下命令形式读取和写入varflags到数据存储区：

      = d.getVarFlags（“”）
     self.d.setVarFlags（“FOO”，{“func”：True}）

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

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

dirs： 应在任务运行之前创建的目录。
cleandirs： 在任务运行之前应创建的空目录。
noexec： 将任务标记为空并且不需要执行。该noexec标志可用于将任务设置为依赖项占位符，或用于禁用在其他位置定义的特定配方中不需要的任务。
nostamp： 告诉BitBake不为任务生成戳记文件，这意味着应始终执行任务。
fakeroot： 使任务在fakeroot环境中运行，通过将变量添加 FAKEROOTENV 到环境中获得。
umask： 运行任务的umask。
deptask： 控制任务构建时依赖性。有关更多信息，请参阅 DEPENDS 变量和“构建依赖关系 ”部分。
rdeptask： 控制任务运行时依赖项。有关详细信息，请参阅 RDEPENDS 变量， RRECOMMENDS变量和“运行时依赖关系 ”部分。
recrdeptask： 控制任务递归运行时依赖项。有关更多信息，请参阅 RDEPENDS 变量， RRECOMMENDS变量和“递归依赖关系 ”部分。
depends： 控制任务间依赖关系。有关更多信息，请参阅 DEPENDS 变量和“任务间依赖关系 ”部分。
rdepends： 控制任务间运行时依赖性。有关更多信息RDEPENDS ，请参阅变量， RRECOMMENDS 变量和“任务间依赖关系 ”部分。
postfuncs： 完成任务后要调用的函数列表。
prefuncs： 在任务执行之前调用的函数列表。
stamp-extra-info： 附加标记信息以附加到任务标记。例如，OpenEmbedded使用此标志来允许特定于计算机的任务。

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

vardeps： 指定一个以空格分隔的附加变量列表，以便为计算其签名添加到变量的依赖项中。向该列表添加变量很有用，例如，当函数以不允许BitBake自动确定引用变量的方式引用变量时。
vardepvalue： 如果设置，则指示BitBake忽略变量的实际值，而是在计算变量的签名时使用指定的值。
vardepsexclude： 指定一个以空格分隔的变量列表，这些变量应该从变量的依赖项中排除，以便计算其签名。
vardepvalueexclude： 指定在计算变量签名时要从变量的值中排除的以管道分隔的字符串列表。

3.7。活动

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

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

     addhandler myclass_eventhandler
     python myclass_eventhandler（）{
         来自bb.event import getName
         来自bb导入数据
         print（“事件的名称是％s”％getName（e））
         print（“我们运行的文件是％s”％data.getVar（'FILE'，e.data，True））
     }

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

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

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 变量启用。

注意

此类扩展的机制非常特定于实现。通常情况下，配方的 PROVIDES， PN和 DEPENDS 变量需要通过扩展类进行修改。对于具体的示例，请参阅OE核心native，nativesdk和multilib类。

BBCLASSEXTEND： 此变量是一个空格分隔的类列表，用于“扩展”每个变体的配方。这是一个示例，导致当前配方的第二个化身可用。第二个化身将继承“本机”类。
```
     BBCLASSEXTEND =“原生”
                    
```
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之后添加addtask printdate

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

3.9.2。建立依赖关系

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

     do_configure [deptask] =“do_populate_staging”

在此示例中，do_populate_staging 每个项目的任务DEPENDS必须在do_configure执行之前完成。

3.9.3。运行时依赖项

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

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

     do_package_write [rdeptask] =“do_package”

在前面的示例中，do_package 每个项目的任务RDEPENDS必须在do_package_write执行之前完成。

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_staging”

在此示例中，do_populate_staging 目标的任务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”设置为“value”。
`d.appendVar("X", "value")`	将“值”添加到变量“X”的末尾。
`d.prependVar("X", "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”的所有标志。

3.11。任务校验和和Setscene

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

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

STAMP：创建戳记文件的基本路径。
STAMPCLEAN 同样，创建戳记文件的基本路径，但可以使用通配符匹配一系列文件以进行清理操作。
BB_STAMP_WHITELIST 列出戳记策略为“白名单”时查看的戳记文件。
BB_STAMP_POLICY 定义用于比较戳记文件的时间戳的模式。
BB_HASHCHECK_FUNCTION 指定在任务执行的“setscene”部分期间调用的函数的名称，以验证任务哈希列表。
BB_SETSCENE_VERIFY_FUNCTION 指定要在主任务执行发生之前验证计划任务执行列表的调用函数。
BB_SETSCENE_DEPVALID 指定一个函数BitBake调用，用于确定BitBake是否需要满足setscene依赖项。
BB_TASKHASH 在执行任务中，此变量保存当前启用的签名生成器返回的任务的哈希值。

第4章文件下载支持

4.1。下载（取指）

4.2。解包

4.3。取程序

4.3.1。本地文件提取器（file://）

4.3.2。CVS fetcher（(cvs://）

4.3.3。HTTP / FTP wget的提取器（http://，ftp://，https://）

4.3.4。Subversion（SVN）Fetcher（svn://）

4.3.5。GIT Fetcher（git://）

4.3.6。其他Fetchers

4.4。自动修订

BitBake的fetch模块是一个独立的库代码，用于处理从远程系统下载源代码和文件的复杂性。获取源代码是构建软件的基石之一。因此，该模块构成了BitBake的重要组成部分。

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

4.1。下载（取指）

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

执行此过程的第一部分（fetch）的代码如下所示：

     src_uri =（d.getVar（'SRC_URI'，True）或“”）。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使用的变量相匹配。

在SRC_URI和WORKDIR 变量不编码到取出器。它们可以（并且）使用不同的变量名调用它们。例如，在OpenEmbedded中，共享状态（sstate）代码使用获取模块来获取sstate文件。

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

预镜像站点： BitBake首先使用预镜来尝试查找源文件。这些位置是使用PREMIRRORS 变量定义的。
源URI： 如果预镜像失败，BitBake使用原始URL（例如，来自 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;协议HTTP =

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

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

     PREMIRRORS？=“\
         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“

     MIRRORS = +“\
         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 变量指定。

文件完整性对于重现构建至关重要。对于非本地存档下载，提取程序代码可以验证sha256和md5校验和，以确保已正确下载存档。您可以通过使用SRC_URI具有相应varflags 的变量来指定这些校验和，如下所示：

     SRC_URI [md5sum] =“价值”
     SRC_URI [sha256sum] =“价值”

您还可以将校验和指定为参数 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”标记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解包到根目录中指定的子目录。

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

如上所述，Git fetcher有自己的unpack方法，该方法经过优化可与Git树一起使用。基本上，此方法通过将树克隆到最终目录中来工作。使用引用完成该过程，因此只需要一个Git元数据的中央副本。

4.3。取程序

如前所述，URL前缀确定BitBake使用哪个fetcher子模块。每个子模块都可以支持不同的URL参数，这些参数将在以下各节中介绍。

4.3.1。本地文件提取器（`file://`）

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

注意

FILESDIR已弃用，可以替换为FILESPATH。因为FILESDIR可能会被删除，所以不应在任何新代码中使用此变量。

如果找不到该文件，则假定在调用DL_DIR 该download()方法时它可用。

以下是一些示例网址：

     SRC_URI =“file：//relativefile.patch”
     SRC_URI =“file：//relativefile.patch; this = ignored”
     SRC_URI =“file：/// Users / ich / very_important_software”

4.3.2。CVS fetcher（`(cvs://`）

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

FETCHCMD_cvs： 运行cvs命令时要使用的可执行文件的名称。这个名字通常是“cvs”。
SRCDATE： 获取CVS源代码时使用的日期。特殊值“now”导致在每次构建时更新结帐。
CVSDIR： 指定保存临时结帐的位置。位置经常DL_DIR/cvs。
CVS_PROXY_HOST： 用作命令的“proxy =”参数的名称 cvs。
CVS_PROXY_PORT： 用作命令的“proxyport =”参数的端口号cvs。

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

支持的参数如下：

“method”： 与cvs服务器通信的协议。默认情况下，此协议为“pserver”。如果“method”设置为“ext”，则BitBake检查“rsh”参数并设置CVS_RSH。您可以将“dir”用于本地目录。
“module”： 指定要签出的模块。您必须提供此参数。
“tag”： 描述应该使用哪个CVS TAG进行结账。默认情况下，TAG为空。
“date”： 指定日期。如果未指定“日期”， SRCDATE 则使用配置来签出特定日期。“now”的特殊值导致每次构建时都会更新结帐。
“localdir”： 用于重命名模块。实际上，您正在重命名解压缩模块的输出目录。您正在将模块强制转换为相对于的特殊目录CVSDIR。
“rsh” 与“method”参数一起使用。
“scmdata”： 当设置为“keep”时，导致CVS元数据在 fetcher创建的tarball中维护。tarball扩展到工作目录。默认情况下，将删除CVS元数据。
“fullpath”： 控制生成的结帐是在模块级别，这是默认值，还是在更深的路径上。
“norecurse”： 使得fetcher仅检出指定的目录而不会递归到任何子目录。
“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.3。HTTP / FTP wget的提取器（`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”

4.3.4。Subversion（SVN）Fetcher（`svn://`）

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

支持的参数如下：

“module”： 要结帐的svn模块的名称。您必须提供此参数。您可以将此参数视为所需存储库数据的顶级目录。
“protocol”： 要使用的协议，默认为“svn”。其他选项是“svn + ssh”和“rsh”。对于“rsh”，也使用“rsh”参数。
“rev”： 结帐的源代码修订版。
“date”： 结帐源代码的日期。特定修订通常比结账更安全，而不是按日期，因为它们不涉及时区（例如，它们更具确定性）。
“scmdata”： 当设置为“keep”时，使“.svn”目录在编译期间可用。默认情况下，将删除这些目录。

以下是使用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 Fetcher（`git://`）

该fetcher子模块从Git源控制系统中获取代码。提取器的工作原理是创建一个裸的克隆，GITDIR通常是DL_DIR/git。在签出特定树时，在解包阶段将此裸克隆克隆到工作目录中。这是通过使用替换和引用来完成的，以最小化磁盘上的重复数据量并使解包过程快速进行。使用的可执行文件可以设置 FETCHCMD_git。

此fetcher支持以下参数：

“protocol”： 用于获取文件的协议。设置主机名时，默认为“git”。如果未设置主机名，则Git协议为“file”。您还可以使用“http”，“https”，“ssh”和“rsync”。
“nocheckout”： 告诉收件人在设置为“1”时解压缩时不签出源代码。为URL设置此选项，其中有一个自定义例程来检出代码。默认值为“0”。
“rebaseable”： 表示可以对上游Git存储库进行重新定位。如果修订可以从分支分离，则应将此参数设置为“1”。在这种情况下，源镜像tarball每次修订都会完成，这会降低效率。重新绑定上游Git存储库可能导致当前修订从上游存储库中消失。此选项提醒提取程序仔细保留本地缓存以供将来使用。此参数的默认值为“0”。
“nobranch”： 告诉提取器设置为“1”时不检查分支的SHA验证。默认值为“0”。为引用对标记而不是分支有效的提交的配方设置此选项。
“bareclone”： 告诉 fetcher将裸克隆克隆到目标目录而不检查工作树。仅提供原始Git元数据。该参数也暗示了“nocheckout”参数。
“branch”： 要克隆的Git树的分支。如果未设置，则假定为“主”。分支参数的数量与名称参数的数量非常匹配。
“rev”： 用于结账的修订版。默认为“master”。
“tag”： 指定用于结帐的标记。要正确解析标记，BitBake必须访问网络。因此，通常不使用标签。就Git而言，“tag”参数的行为与“revision”参数的行为有效。
“subpath”： 将结帐限制为树的特定子路径。默认情况下，检出整个树。
“destsuffix”： 放置结帐的路径的名称。默认情况下，路径为git/。

以下是一些示例网址：

     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。其他Fetchers

以下还存在获取子模块：

Bazaar（bzr://）
Perforce（p4://）
Git子模块（gitsm://）
树木使用Git附件（gitannex://）
安全FTP（sftp://）
安全壳（ssh://）
回购（repo://）
OSC（osc://）
Mercurial（hg://）

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

4.4。自动修订

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

第5章变量词汇表

词汇表

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

注意

以下是本词汇表中列出的变量的一些要点：

本词汇表中列出的变量特定于BitBake。因此，描述仅限于该上下文。
此外，其他使用BitBake的系统中存在变量（例如Yocto Project和OpenEmbedded），其名称与本词汇表中的名称相同。对于这种情况，这些系统中的变量扩展了变量的功能，如本词汇表中所述。
最后，本词汇表中提到的变量未出现在BitBake词汇表中。这些其他变量是使用BitBake的系统中使用的变量。

词汇表

A B C D E F H L M O P R S T.

一个

ASSUME_PROVIDED

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

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

乙

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

BB_CONSOLELOG

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

BB_CURRENTTASK

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

BB_DANGLINGAPPENDS_WARNONLY

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

默认的致命行为是最安全的，因为如果某些事情不同步，这是理智的反应。重要的是要意识到何时不再应用您的更改。

BB_DEFAULT_TASK

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

BB_DISKMON_DIRS

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

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

     BB_DISKMON_DIRS =“，， [...]”

     哪里：

        是：
           ABORT：立即中止构建
                      门槛被打破了。
           STOPTASKS：在当前之后停止构建
                      执行任务时已完成
                      门槛被打破了。
           警告：发出警告但继续
                      在阈值被破坏时构建。
                      后续警告发布为
                      由...定义
                      BB_DISKMON_WARNINTERVAL变量，
                      必须定义。

        是：
           您选择的任何目录。您可以指定一个或
           通过分离来监视更多目录
           有空间的分组。如果有两个目录
           在同一台设备上，只有第一个目录
           受到监控。

        是：
           最小可用磁盘空间，
           最小数量的免费inode，或
           都。您必须至少指定一个。至
           省略一个或另一个，只是省略值。
           使用G，M，K为Gbytes指定阈值，
           分别为Mbytes和Kbytes。如果你这样做
           不指定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}低于1 GB或可用的空闲inode降至100 KB以下时，此示例会导致构建系统立即中止。由于变量提供了两个目录，因此当${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 =“WARN，$ {SSTATE_DIR}，1G，100K”
     BB_DISKMON_WARNINTERVAL =“50M，5K”

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

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不会搜索主要 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函数列表比调用许多单个任务更容易。返回的列表不一定完全准确。给定的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

     运行。{任务} {} PID

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

BB_RUNTASK

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

BB_SCHEDULER

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

basic - 一切都来自的基本框架。使用此选项会导致任务在解析时按数字顺序排序。
速度 - 首先执行具有更多任务的任务，具体取决于它们。“速度”选项是默认选项。
完成 - 使调度程序在构建开始后尝试完成给定的配方。

BB_SCHEDULERS

定义要导入的自定义计划程序。自定义调度程序需要从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

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

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

cache - 保留系统先前获得的值，而不是每次查询源控制系统。
clear - 每次查询源控件系统。使用此策略，没有缓存。“清除”策略是默认策略。

BB_STAMP_POLICY

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

perfile - 时间戳比较仅在特定配方的时间戳之间进行。这是默认模式。
full - 对所有依赖项进行时间戳比较。
白名单 - 与“完整”模式相同，但时间戳比较是针对BB_STAMP_WHITELIST 变量中列出的食谱进行的。

注意

随着setscene任务的引入，邮票政策基本上已经过时。

BB_STAMP_WHITELIST

列出当戳记策略模式设置为“白名单”时比较戳记文件时间戳的文件。有关戳记策略的信息，请参阅 BB_STAMP_POLICY 变量。

BB_STRICT_CHECKSUM

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

BB_TASK_NICE_LEVEL

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

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

BB_TASKHASH

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

BB_VERBOSE_LOGS

控制在构建期间详细的BitBake。如果设置，则shell脚本echo命令和shell脚本输出显示在标准输出（stdout）上。

BB_WORKERCONTEXT

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

BBCLASSEXTEND

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

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

     BBCLASSEXTEND = +“native nativesdk”
     BBCLASSEXTEND = +“multilib：”

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用于构建软件的配方文件列表。

BBINCLUDED

包含在解析当前文件时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。

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。=“|。* openldap”
     BBMASK。=“|。* opencv”
     BBMASK。=“|。* lzma”

注意垂直条如何用于附加片段。

注意

指定目录名称时，请使用尾部斜杠字符以确保仅匹配该目录名称。

BBPATH

由BitBake用于定位class（.bbclass）和configuration（.conf）文件。该变量类似于 PATH变量。

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

     $ BBPATH =“”
     $ export BBPATH
     $ bitbake

BBSERVER

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

BBVERSIONS

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

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

BITBAKE_UI

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

注意

您必须在外部环境中设置此变量才能使其工作。

BUILDNAME

分配给构建的名称。名称默认为构建开始时的日期时间戳，但可以由元数据定义。

C

CACHE

指定BitBake用于存储元数据缓存的目录，因此每次启动BitBake时都不需要解析它。

d

DEFAULT_PREFERENCE

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

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

注意

如果该变量在包含相同配方的不同版本的两个层之间不同DEFAULT_PREFERENCE ，BBFILE_PRIORITY则所提供的偏差很弱并被覆盖。

要看

列出配方的构建时依赖项（即其他配方文件）。

考虑这个名为“a”和“b”的两个配方的简单示例，它们生成类似命名的包。在此示例中，DEPENDS 语句显示在“a”配方中：

     DEPENDS =“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的

包含在fakeroot环境中运行shell脚本时要使用的命令。该FAKEROOT变量是过时，已被其他已被替换 FAKEROOT*的变量。有关详细信息，请参阅词汇表中的这些条目。

FAKEROOTBASEENV

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

FAKEROOTCMD

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

FAKEROOTDIRS

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

FAKEROOTENV

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

FAKEROOTNOENV

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

FETCHCMD

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

文件

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

FILESDIR

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

注意

该FILESDIR变量已弃用，您应该 FILESPATH在所有新代码中使用。

FILESPATH

指定BitBake在搜索补丁和文件时使用的目录。处理file://URL 时，“本地”fetcher模块使用这些目录。该变量的行为类似于shell PATH 环境变量。该值是以冒号分隔的目录列表，按顺序从左向右搜索。

H

主页

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

一世

继承

在解析期间使此命名类在此时继承。该变量仅在配置文件中有效。

大号

LAYERDEPENDS

列出由空格分隔的层，此配方依赖于这些层。（可选）您可以通过使用冒号将其添加到图层名称的末尾来指定依赖项的特定图层版本（例如，“anotherlayer：3”将在此情况下进行比较）。如果缺少任何依赖项或版本号不完全匹配（如果指定），则BitBake会产生错误。LAYERVERSION_anotherlayer

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

LAYERDIR

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

LAYERVERSION

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

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

执照

配方的源许可证列表。

中号

镜子

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

MULTI_PROVIDER_WHITELIST

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

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

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

Ø

覆盖

BitBake的使用OVERRIDES控制BitBake的食谱分析和配置文件后，将被覆盖哪些变量。您可以在“ 条件语法（覆盖）”部分中找到有关如何处理覆盖的更多信息。

P

套餐

食谱创建的包列表。

PACKAGES_DYNAMIC

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

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

PERSISTENT_DIR

指定BitBake用于存储应在构建之间保留的数据的目录。特别是，存储的数据是使用BitBake的持久数据API以及PR服务器和PR服务使用的数据的数据。

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

食谱名称。

食谱的修订。

PREFERRED_PROVIDER

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

     PREFERRED_PROVIDER_virtual / kernel？=“linux-yocto”
     PREFERRED_PROVIDER_virtual / xserver =“xserver-xf86”
     PREFERRED_PROVIDER_virtual / libgl？=“mesa”

PREFERRED_PROVIDERS

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

     PREFERRED_PROVIDERS =“xxx：yyy aaa：bbb ......”

此表单是以下方便的替代：

     PREFERRED_PROVIDER_xxx =“yyy”
     PREFERRED_PROVIDER_aaa =“bbb”

PREFERRED_VERSION

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

     PREFERRED_VERSION_python =“2.7.3”
     PREFERRED_VERSION_linux-yocto =“3.10％”

PREMIRRORS

通常，您可以通过向配置中添加以下内容，为构建系统添加特定服务器，以便在任何其他服务器之前尝试：

     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指向本地目录或网络共享。

现状提供

配方还提供的别名列表。这些别名对于在构建期间满足其他配方的依赖性非常有用（由指定 DEPENDS）。

注意

配方自己 PN 已隐含在其 PROVIDES列表中。

PRSERV_HOST

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

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

     PRSERV_HOST =“localhost：0”

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

食谱的版本。

[R

RDEPENDS

列出必须安装的软件包的运行时依赖项（即其他软件包），以便构建的软件包能够正确运行。如果在构建期间找不到此列表中的包，则会出现生成错误。

由于该RDEPENDS变量适用于正在构建的包，因此应始终在具有附加包名称的表单中使用该变量。例如，假设您正在构建依赖于perl包的开发包。在这种情况下，您将使用以下 RDEPENDS语句：

     RDEPENDS _ $ {PN} -dev + =“perl”

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

BitBake支持指定版本化依赖项。虽然语法因打包格式而异，但BitBake会隐藏这些差异。以下是使用RDEPENDS变量指定版本的一般语法：

     RDEPENDS _ $ {PN} =“（ ）”

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

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

     RDEPENDS _ $ {PN} =“foo（> = 1.2）”

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

RPROVIDES

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

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

     RPROVIDES _ $ {PN} =“widget-abi-2”

RRECOMMENDS

一个包列表，它扩展了正在构建的包的可用性。正在构建的软件包不依赖于此软件包列表以便成功构建，但需要它们以实现扩展的可用性。要指定包的运行时依赖性，请参阅该 RDEPENDS 变量。

BitBake支持指定版本化建议。虽然语法因打包格式而异，但BitBake会隐藏这些差异。以下是使用RRECOMMENDS变量指定版本的一般语法：

     RRECOMMENDS _ $ {PN} =“（ ）”

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

例如，以下内容在软件包1.2或更高版本上建议foo：

     RRECOMMENDS _ $ {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://-从安全shell获取文件。
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如果需要，只添加一个占位符。并且，此占位符位于返回的字符串的开头。

邮票

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

STAMPCLEAN

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

摘要

配方的简短摘要，不超过72个字符。

Ť

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

TOPDIR

指向构建目录。BitBake自动设置此变量。

附录A. Hello World示例

A.1。BitBake Hello World

A2。获得BitBake

A.3。设置BitBake环境

A.4。Hello World示例

A.1。BitBake Hello World

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

A2。获得BitBake

有关如何获取BitBake的信息，请参阅“ 获取BitBake ”部分。在计算机上安装源代码后，BitBake目录如下所示：

     $ ls -al
     总共100
     drwxrwxr-X。9 wmat wmat 4096 Jan 31 13:44。
     drwxrwxr-X。3 wmat wmat 4096 Feb 4 10:45 ..
     -rw-RW-R--。1 wmat wmat 365 11月26 04:55作者
     drwxrwxr-X。2 wmat wmat 4096 11月26日04:55 bin
     drwxrwxr-X。4 wmat wmat 4096 Jan 31 13:44 build
     -rw-RW-R--。1 wmat wmat 16501 11月26日04:55 ChangeLog
     drwxrwxr-X。2 wmat wmat 4096 11月26日04:55班
     drwxrwxr-X。2 wmat wmat 4096 11月26日04:55 conf
     drwxrwxr-X。3 wmat wmat 4096 11月26日04:55 contrib
     -rw-RW-R--。1 wmat wmat 17987 11月26日04:55复制
     drwxrwxr-X。3 wmat wmat 4096 11月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
     -rwxrwxr-X。1 wmat wmat 3195 Jan 31 11:57 setup.py
     -rw-RW-R--。1 wmat wmat 2887 11月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输入以下内容查看当前变量：

     $ echo $ 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项目等现代项目如何利用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~ /你好
     $ cd~ / hello
                
```
这是BitBake用于完成所有工作的目录。您可以使用此目录来保留BitBake所需的所有元文件。拥有项目目录是隔离项目的好方法。

运行Bitbake： 此时，您只有一个项目目录。运行该bitbake命令，看看它的作用：

     $ bitbake
     BBPATH变量未设置，bitbake没有
     在预期位置找到conf / bblayers.conf文件。
     也许你不小心从错误的目录中调用了bitbake？
     DEBUG：从环境中删除以下变量：
     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，EDITOR，
     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 =“”
     $ export BBPATH
                
```
在命令中使用实际的项目目录。BitBake使用该目录来查找项目所需的元数据。

注意
在指定项目目录时，不要使用波浪号（“〜”）字符，因为BitBake不会像shell那样扩展该字符。

运行Bitbake： 现在已经BBPATH定义，bitbake再次运行命令：

     $ bitbake
     错误：回溯（最近一次调用最后一次）：
       文件“/home/scott-lenovo/bitbake/lib/bb/cookerdata.py”，第163行，包裹
         return func（fn，* args）
       在parse_config_file中输入文件“/home/scott-lenovo/bitbake/lib/bb/cookerdata.py”，第173行
         return bb.parse.handle（fn，data，include）
       文件“/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py”，第99行，句柄
         return h ['handle']（fn，data，include）
       文件“/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py”，第120行，句柄
         abs_fn = resolve_file（fn，data）
       在resolve_file中输入文件“/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py”，第117行
         引发IOError（“在％s中找不到文件％s”％（fn，bbpath））
     IOError：/ home / scott-lenovo / hello中找不到文件conf / bitbake.conf

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

此示例输出显示BitBake无法conf/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 /＃的-概述-的-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行，包裹
    return func（fn，* args）
  在_inherit中输入“/home/scott-lenovo/bitbake/lib/bb/cookerdata.py”，第177行
    bb.parse.BBHandler.inherit（bbclass，“配置INHERITs”，0，数据）
  文件“/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py”，第92行，继承
    include（fn，file，lineno，d，“inherit”）
  文件“/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py”，第100行，包括
    引发ParseError（“无法％（error_out）s文件％（fn）s”％vars（），oldfn，lineno）
ParseError：配置中的ParseError INHERITs：无法继承文件类/ base.bbclass

错误：无法解析基础：配置中的ParseError INHERITs：无法继承文件类/ 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通过插入以下单行创建文件：
```
     addtask build
                
```
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 /＃任务。
运行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-找到有关添加图层的更多信息。 an-image / #additional-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（“* Hello，World！*”）;
        bb.plain（“* *”）;
        bb.plain（ “******”）;
     }
                
```
配方文件只提供配方，名称，版本和do_build 任务的描述，它将“Hello World”打印到控制台。有关这些变量的更多信息，请单击词汇表的链接。
使用目标运行Bitbake： 现在存在BitBake目标，运行命令并提供该目标：
```
     $ cd $ HOME /你好
     $ bitbake printhello
     错误：没有要构建的配方文件，检查你的BBPATH和BBFILES？

     摘要：显示了1个ERROR消息，返回非零退出代码。
                
```
我们已经使用配方和图层配置文件创建了图层，但似乎BitBake仍无法找到配方。BitBake需要一个conf/bblayers.conf列出项目层的a 。没有这个文件，BitBake无法找到配方。
创建conf/bblayers.conf： BitBake使用该conf/bblayers.conf文件来定位项目所需的图层。该文件必须位于conf项目的目录中（即hello/conf本例）。

将工作目录设置为hello/conf 目录，然后创建该bblayers.conf 文件，使其包含以下内容：
```
     BBLAYERS？=“\
       / home /  / mylayer \
       “
                
```
您需要you在文件中提供自己的信息。
使用目标运行Bitbake： 现在您已经提供了bblayers.conf 文件，运行bitbake命令并提供目标：
```
     $ bitbake printhello
     解析配方：100％| ############################################ ###################################### |
     时间：00：00：00
     解析1 .bb文件完成（0缓存，1解析）。1个目标，0个跳过，0个屏蔽，0个错误。
     注意：解决任何丢失的任务队列依赖项
     注意：准备runqueue
     注意：执行RunQueue任务
     ********************
     * *
     * 你好，世界！*
     * *
     ********************
     注意：任务摘要：尝试了1个任务，其中0不需要重新运行且全部成功。
                
```
BitBake找到printhello配方并成功运行任务。

注意
第一次执行后，再次重新运行 bitbake printhello不会导致打印相同控制台输出的BitBake运行。原因是第一次 printhello.bb配方的 do_build任务成功执行时，BitBake会为任务写一个戳记文件。因此，下次尝试使用相同的bitbake命令运行任务时，BitBake会注意到标记，因此确定不需要重新运行任务。如果删除tmp目录或运行bitbake -c clean printhello 然后重新运行构建，“Hello，World！” 消息将再次打印。

BitBake User Manual（译）

第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。例子

注意

第2章执行

注意

2.1。解析基本配置元数据

注意

2.2。定位和解析食谱

注意

注意

2.3。偏好和提供者

2.4。依赖

2.5。任务列表

注意

2.6。执行任务

2.7。校验和（签名）

注意

2.8。Setscene

第3章语法和运算符

3.1。基本语法

3.1.1。基本变量设置

3.1.2。可变扩展

3.1.3。设置默认值（？=）

注意

3.1.4。设置弱默认值（?? =）

3.1.5。立即变量扩展（：=）

3.1.6。使用Spaces追加（+ =）和前置（= +）

3.1.7。在没有空格的情况下追加（。=）和前置（=。）

3.1.8。追加和前置（覆盖样式语法）

注意

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。Shell函数

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.3.2。 `inherit`指示

3.3.3。 `include`指示

3.3.4。 `require`指示

3.3.5。 `INHERIT`配置指令

3.9.1。`.bb`文件内部的依赖关系

4.3.1。本地文件提取器（`file://`）

4.3.2。CVS fetcher（`(cvs://`）

4.3.3。HTTP / FTP wget的提取器（`http://`，`ftp://`，`https://`）

4.3.4。Subversion（SVN）Fetcher（`svn://`）

4.3.5。GIT Fetcher（`git://`）