写在前面的废话：工作驱动，Yocto Project拔草，后面有心情就接着翻其他文档
src_url：https://www.yoctoproject.org/docs/3.1.2/bitbake-user-manual/bitbake-user-manual.html
第三章“语法和操作”篇幅较长，单独翻译：BitBake用户手册-3.语法和操作

1. 概述

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

1.1 介绍

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

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

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

1.2 历史和目标

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

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

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

在BitBake之前，没有其他构建工具可以充分满足有抱负的嵌入式Linux发行版的需求。传统桌面Linux发行版使用的所有构建系统都缺少一些重要的功能，并且嵌入式领域中流行的基于Buildroot的专用系统都没有可伸缩性或可维护性。

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

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

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

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

BitBake满足了所有最初的要求，并且通过对基本功能进行了扩展以反映附加要求，从而满足了更多要求。灵活性和强大(power)一直是我们的首要任务。 BitBake具有高度的可扩展性，并支持嵌入式Python代码和任意任务的执行。

1.3 概念

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

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

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

1.3.1 配方(Recipes)

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

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

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

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

1.3.2 配置文件(Configuraion Files)

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

1.3.3 类(Classes)

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

1.3.4 层(Layers)

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

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

1.3.5 附加文件(Append Files)

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

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

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

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

busybox_1.21.％.bbappend

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

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

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

如果busybox配方已更新为busybox_1.3.0.bb，则追加名称将不匹配。但是，如果您将附加文件命名为busybox_1.％.bbappend，则可以匹配。
通常，您可以将附加文件命名为busybox _％.bbappend之类的简单名称，使其完全独立于版本。

1.4 获取BitBake

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

克隆BitBake：使用Git克隆BitBake源代码存储库是获得BitBake的推荐方法。克隆存储库可以轻松获得错误修复，并可以访问稳定的分支和master分支。克隆BitBake后，应使用最新的稳定分支进行开发，因为主分支用于BitBake开发，并且可能包含一些不稳定修改。
通常，您需要一个与您使用的元数据匹配的BitBake版本。元数据通常向后兼容，但不向前兼容。
这是克隆BitBake存储库的示例：
```
$ git clone git：//git.openembedded.org/bitbake
```
此命令将BitBake Git存储库克隆到一个名为bitbake的目录中。另外，如果您不想将目录命名为bitbake，则可以在git clone命令之后指定目录。这是一个命名目录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
```
使用您构建系统检出附带的BitBake：获得BitBake副本的最后一种可能性是，它已经随您检出的基于BitBake的大型构建系统（例如Poky）一起提供。您可以检出整个构建系统，而不是手动检出各个层并将其自己粘在一起。结帐将已经包含经过彻底测试的与其他组件兼容性的BitBake版本。有关如何检出基于BitBake的特定构建系统的信息，请参阅该构建系统的支持文档。

1.5 BitBake命令

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

1.5.1 用法和语法

以下是BitBake的用法和语法：

$ bitbake -hUsage: bitbake [options] [recipename/target recipe:do_task ...]Executes the specified task (default is 'build') for a given set of target recipes (.bb files).It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH whichwill provide the layer, BBFILES and other configuration information.Options:--version             show program's version number and exit-h, --help            show this help message and exit-b BUILDFILE, --buildfile=BUILDFILEExecute tasks from a specific .bb recipe directly.WARNING: Does not handle any dependencies from otherrecipes.-k, --continue        Continue as much as possible after an error. While thetarget that failed and anything depending on it cannotbe built, as much as possible will be built beforestopping.-f, --force           Force the specified targets/task to run (invalidatingany existing stamp file).-c CMD, --cmd=CMD     Specify the task to execute. The exact optionsavailable depend on the metadata. Some examples mightbe 'compile' or 'populate_sysroot' or 'listtasks' maygive a list of the tasks available.-C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMPInvalidate the stamp for the specified task such as'compile' and then run the default task for thespecified target(s).-r PREFILE, --read=PREFILERead the specified file before bitbake.conf.-R POSTFILE, --postread=POSTFILERead the specified file after bitbake.conf.-v, --verbose         Enable tracing of shell tasks (with 'set -x'). Alsoprint bb.note(...) messages to stdout (in addition towriting them to ${T}/log.do_<task>).-D, --debug           Increase the debug level. You can specify this morethan once. -D sets the debug level to 1, where onlybb.debug(1, ...) messages are printed to stdout; -DDsets the debug level to 2, where both bb.debug(1, ...)and bb.debug(2, ...) messages are printed; etc.Without -D, no debug messages are printed. Note that-D only affects output to stdout. All debug messagesare written to ${T}/log.do_taskname, regardless of thedebug level.-q, --quiet           Output less log message data to the terminal. You canspecify this more than once.-n, --dry-run         Don't execute, just go through the motions.-S SIGNATURE_HANDLER, --dump-signatures=SIGNATURE_HANDLERDump out the signature construction information, withno task execution. The SIGNATURE_HANDLER parameter ispassed to the handler. Two common values are none andprintdiff but the handler may define more/less. nonemeans only dump the signature, printdiff means comparethe dumped signature with the cached one.-p, --parse-only      Quit after parsing the BB recipes.-s, --show-versions   Show current and preferred versions of all recipes.-e, --environment     Show the global or per-recipe environment completewith information about where variables wereset/changed.-g, --graphviz        Save dependency tree information for the specifiedtargets in the dot syntax.-I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDEDAssume these dependencies don't exist and are alreadyprovided (equivalent to ASSUME_PROVIDED). Useful tomake dependency graphs more appealing-l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINSShow debug logging for the specified logging domains-P, --profile         Profile the command and save reports.-u UI, --ui=UI        The user interface to use (knotty, ncurses or taskexp- default knotty).--token=XMLRPCTOKEN   Specify the connection token to be used whenconnecting to a remote server.--revisions-changed   Set the exit code depending on whether upstreamfloating revisions have changed or not.--server-only         Run bitbake without a UI, only starting a server(cooker) process.-B BIND, --bind=BIND  The name/address for the bitbake xmlrpc server to bindto.-T SERVER_TIMEOUT, --idle-timeout=SERVER_TIMEOUTSet timeout to unload bitbake server due toinactivity, set to -1 means no unload, default:Environment variable BB_SERVER_TIMEOUT.--no-setscene         Do not run any setscene tasks. sstate will be ignoredand everything needed, built.--setscene-only       Only run setscene tasks, don't run any real tasks.--remote-server=REMOTE_SERVERConnect to the specified server.-m, --kill-server     Terminate any running bitbake server.--observe-only        Connect to a server as an observing-only client.--status-only         Check the status of the remote bitbake server.-w WRITEEVENTLOG, --write-log=WRITEEVENTLOGWrites the event log of the build to a bitbake eventjson file. Use '' (empty string) to assign the nameautomatically.--runall=RUNALL       Run the specified task for any recipe in the taskgraphof the specified target (even if it wouldn't otherwisehave run).--runonly=RUNONLY     Run only the specified task within the taskgraph ofthe specified targets (and any task dependencies thosetasks may have).

1.5.2 示例

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

1.5.2.1 针对单个配方执行任务

对单个配方文件执行任务相对简单。您指定特定文件，然后BitBake解析该文件并执行指定的任务。如果您未指定任务，则BitBake将执行默认任务“ build”。

以下命令在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哪些文件可用，以及哪些文件要执行。还需要一种方法来说明构建和运行每个配方时的其依赖性。当多个配方提供相同的功能或一个配方有多个版本时，必须有一种表达配方首选项的方法。

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

$ bitbake foo

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

$ bitbake -c clean foo

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

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

$ bitbake myfirstrecipe:do_taskA mysecondrecipe:do_taskB

1.5.2.4 生成依赖图

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

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

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

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

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

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

1.5.2.5 执行多配置构建

BitBake能够使用一个命令构建多个镜像或程序包，其中不同的目标需要不同的配置（多个配置构建）。该场景下，每个目标都称为“ multiconfig”。
要完成多重配置构建，必须使用构建目录中的并行配置文件分别定义每个目标的配置。这些multiconfig配置文件的位置是特定的。它们必须位于当前构建目录中conf的子目录multiconfig中。以下是两个单独目标的示例：

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

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

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

BBMULTICONFIG =“ target1 target2”

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

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

以下是两个额外的多重配置的示例：target1和target2：

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

1.5.2.6 使能多配置构建依赖

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

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

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

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

image_task [mcdepends] =“ mc:target1:target2:image2:rootfs_task”

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

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

$ bitbake mc:target1:image1

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

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

image_task[mcdepends] =“ mc:target1:target2:image2:image_task”

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

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

2. Execution

运行BitBake的主要目的是产生某种输出，例如单个可安装的软件包，内核，sdk，甚至是完整的，用于特定板子的可引导Linux映像，其中包含引导加载程序，内核和根文件系统。当然，您可以使用使它执行单个任务，编译单个配方文件，捕获或清除数据或仅返回有关执行环境信息。

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

$ bitbake target

在执行BitBake之前，应通过在项目的local.conf配置文件中设置BB_NUMBER_THREADS变量来配置构建主机上可用的并行线程。
确定构建主机的此值的常用方法是运行以下命令：
$ grep processor /proc/ cpuinfo
此命令返回考虑了超线程的处理器数量。因此，具有超线程的四核构建主机最有可能显示八个处理器，这是您将随后分配给BB_NUMBER_THREADS的值。
可能更简单的解决方案是某些Linux发行版（例如Debian和Ubuntu）提供ncpus命令。

2.1 解析基础配置元数据

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

食谱：有关特定软件的详细信息。
类数据：常见构建信息的抽象（例如，如何构建Linux内核）。
配置数据：Machine-specific设置，策略决策等。配置数据充当将所有内容绑定在一起的粘合剂。

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

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

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

BB_ENV_WHITELIST
BB_ENV_EXTRAWHITE
BB_PRESERVE_ENV
BB_ORIGENV
BITBAKE_UI

此列表中的前四个变量与BitBake在任务执行期间如何处理Shell环境变量有关。默认情况下，BitBake清除环境变量并提供对Shell执行环境的严格控制。但是，通过使用前四个变量，您可以对任务执行期间shell中BitBake允许使用的环境变量。

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

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

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

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

bitbake.conf文件中仅允许变量定义和include指令。一些变量直接影响BitBake的行为。这些变量可能是从环境中设置的，具体取决于前面提到的环境变量或在配置文件中设置。

解析配置文件后，BitBake使用其基本的继承机制（通过类文件）来继承一些标准类。当遇到负责获取一个类的继承指令时，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”
###### The following “}” at the start of the line causes a parsing error ######
}
EOF
}
按照以下方式编写recipe可以避免错误：
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 查找并解析配方(Recipes)

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

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

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

说明：
附加文件按在BBFILES中查找到的顺序应用。

对于每个文件，都会制作一个基本配置的新副本，然后逐行分析配方。任何inherit语句都会导致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”。

到对一个配方(recipe)解析完成时，BitBake拥有该recipe定义的任务列表、由键值对组成的数据集以及有关任务的依赖信息。

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 Providers

假定已指定BitBake执行目标，并且已解析所有配方文件，则BitBake开始弄清楚如何构建目标。 BitBake遍历每个配方的"PROVIDES"列表。"PROVIDES"列表是一个名字列表，通过这些名字配方可以被知道。每个配方的PROVIDES列表都是通过配方的PN变量隐式创建的，或者通过配方的PROVIDES变量（可选的）显式创建的。

当配方使用PROVIDES时，除了隐式的PN名称外，可以在一个或多个替代名称下找到该配方的功能。举例来说，假设一个名为keyboard_1.0.bb的食谱包含以下内容：

PROVIDES += "fullkeyboard"

该配方的PROVIDES列表变为“ keyboard”（隐式）和“ fullkeyboard”（显式）。因此，可以在两个不同的名称下找到keyboard_1.0.bb中的功能。

2.4 Preferences

PROVIDES列表只是解析目标配方的解决方案的一部分。因为目标可能有多个提供者，所以BitBake需要通过确定提供者的preference来对提供者进行优先级排序。

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

PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"

默认的PREFERRED_PROVIDER是与目标名称相同的提供者。 BitBake遍历需要构建的每个目标，并解决它们及其依赖项。

由于给定提供者可能存在多个版本，因此了解如何选择提供者变得很复杂。 BitBake默认为provider的最高版本。使用与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。但是，如果在BitBake解析的.conf文件中定义以下变量，则可以更改该选择倾向：

PREFERRED_VERSION_a = "1.1"

说明：
配方通常会提供两个版本-稳定的：编号的（和首选的）版本，以及从源代码存储库自动检出的版本，该版本被认为是“bleeding edge”，但可以显式的选择。
例如，在OpenEmbedded代码库中，有一个用于BusyBox的标准版本食谱文件，busybox_1.22.1.bb，但是也有一个基于Git的版本，busybox_git.bb，其中明确包含该行
DEFAULT_PREFERENCE =“ -1”
用于确保始终首选带编号的稳定版本，除非开发人员另有选择。

2.5 依赖

每个目标BitBake构建都包含多个任务，例如获取，解压缩，修补，配置和编译。为了在多核系统上获得最佳性能，BitBake将每个任务视为具有自己的一组依赖关系的独立实体。

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

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

2.6 任务列表

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

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

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

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

时间戳的格式部分可配。在现代版本的BitBake中，哈希会添加到戳记中，因此，如果配置发生更改，戳记将变为无效，并且任务将自动重新运行。此哈希或使用的签名由配置的签名策略控制（有关信息，请参见“校验和（签名）”部分）。也可以使用[stamp-extra-info]任务标记将额外的元数据添加到stamp。例如，OpenEmbedded使用此标志使某些任务特定于计算机。

注意
一些任务被标记为“ nostamp”任务。运行这些任务时，不会创建任何时间戳文件。因此，“ nostamp”任务始终会重新运行。

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_SCHEDULER
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也不依赖于MACHINE的值。

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

PACKAGE_ARCHS [vardeps] =“MACHINE”

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

考虑内联Python的情况，例如，BitBake无法找出依赖关系。当以调试模式运行时（比如使用-DDD），BitBake在发现无法确定依赖关系的内容时会产生输出。

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

在代码级别，可以通过多种方式影响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的一部分。

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

BB_SIGNATURE_HANDLER？=“ OEBasicHash”

“ OEBasicHash”签名处理程序与“OEBasic”版本相同，但是将任务哈希添加到stamp文件。这样任何元数据更改都会改变任务哈希，从而自动使任务再次运行。这样就无需增加PR值，并且对元数据的更改会自动在整个构建过程中体现。

值得说明的是，这些签名生成器的最终作用是使某些依赖项和哈希信息可用于构建。这些信息包括：

BB_BASEHASH_task-taskname：配方中每个任务的基础哈希。
BB_BASEHASH_filename：taskname：每个相关任务的基础哈希。
BBHASHDEPS_filename：taskname：每个任务的任务依赖性。
BB_TASKHASH：当前正在运行的任务的哈希。

值得注意的是，BitBake的“ -S”选项可让您调试BitBake的签名处理。传递给-S的选项允许使用不同的调试模式，既可以使用BitBake自己的调试功能，也可以使用metadate或signature handle本身定义的调试功能。最简单的传参是“ none”，这将导致一组签名信息被写到对应于指定目标的STAMPS_DIR中。当前另一个可用的参数是“ printdiff”，它使BitBake尝试建立它可以匹配的最接近的签名（例如在状态缓存中），然后对匹配项运行bitbake-diffsigs以确定这两个stamp树的stamp和delta的地方。

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

2.9 设置场景(setscene)

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

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

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

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

BitBake首先调用BB_HASHCHECK_FUNCTION变量定义的函数，并列出要构建的任务列表和相应的哈希值。该函数被设计为高效运行，并返回它认为可以获取工件的任务列表。

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

如前所述，一个工件可能覆盖多个任务。例如，如果您已经具有已编译的二进制文件，则获取编译器毫无意义。为了解决这个问题，BitBake为每个成功的setcene任务调用BB_SETSCENE_DEPVALID函数，以了解是否需要获取该任务的依赖关系。

最后，在执行所有setscene任务之后，BitBake调用BB_SETSCENE_VERIFY_FUNCTION2中列出的函数，并列出BitBake认为已“covered”的任务列表。然后，元数据可以确保此列表正确，并且可以通知BitBake它要运行特定的任务，而不管setscene结果。

2.10 记录日志

除了标准的命令行选项来控制执行时构建的详细信息，bitbake还通过BB_LOGCONFIG变量支持用户定义的Python日志记录配置。此变量定义json或yaml日志记录配置，这些配置将智能地合并到默认配置中。使用以下规则合并日志记录的配置：

如果顶层key：bitbake_merge设置为False，则用户定义的配置将完全替换默认配置。在这种情况下，所有其他规则都将被忽略。
用户配置必须具有顶层版本，该version必须与默认配置的值匹配。
在handlers，formatters或filters中定义的所有键都将被合并到默认配置的相同部分，如果发生冲突，用户指定的键将替换默认键。实际上，这意味着如果默认配置和用户配置都指定了一个名为myhandler的处理程序，则用户定义的处理程序将替换默认值。为防止用户无意间替换默认handlers，formatters或filters，所有默认处理程序均以前缀“BitBake.”命名。
如果用户将键bitbake_merge设置为False，则logger将完全由用户配置代替。在这种情况下，没有其他规则适用于该记录器。
给定logger的所有用户定义的filter和handlers属性都将与默认记录器的相应属性合并。例如，如果用户配置将一个名为myFilter的过滤器添加到BitBake.SigGen，并且默认配置中添加了一个名为BitBake.defaultFilter的过滤器，则这两个过滤器都将应用于logger

例如，请考虑以下用户日志记录配置文件，该文件将VERBOSE或更高版本的所有与Hash Equivalence相关的消息记录到名为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"]}}}

3. 语法和操作

3.1 基础语法

3.2 导出变量到环境变量

3.3 条件语法(覆盖)

3.4 通用功能

3.5 函数

3.6 任务

3.7 变量标志

3.8 事件

3.9 变体-类扩展机制

3.10 依赖

3.11 Python中可以调用的方法

3.12 任务校验和和setscene

3.13 变量通配符

4. 文件下载支持

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

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

4.1 下载(Fetch)

在获取源代码或文件时，BitBake采取了几个步骤。提取程序代码库按顺序处理两个不同的过程：从某个地方（缓存或其他地方）获取文件，然后将这些文件解压缩到特定位置，并且可能以特定方式。在获取和解压缩文件后，通常可以选择是否打补丁。但是，此部分不涵盖打补丁。

执行此过程第一部分的代码，即提取，如下所示：

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

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

通常在fetch类实例化之后跟以下语句：

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

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

说明：
为了方便起见，这些示例中的命名与OpenEmbedded使用的变量匹配。如果要查看上面的代码，请查阅OpenEmbedded类文件base.bbclass。

SRC_URI和WORKDIR变量不会硬编码到提取程序中，因为可以使用不同的变量名来调用这些提取程序方法。例如，在OpenEmbedded中，共享状态（sstate）代码使用fetch模块来访存sstate文件。

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

Pre-mirror Sites：BitBake首先使用pre-mirrors来尝试查找源文件。这些位置是使用PREMIRRORS变量定义的。
Source URI：如果pre-mirrors失败，则BitBake使用原始URL（例如来自SRC_URI的URL）。
Mirror Sites：如果发生提取失败，则BitBake接下来将使用MIRRORS变量定义的镜像位置。

对于传递给提取程序的每个URL，提取程序都会调用处理该特定URL类型的子模块。当您为SRC_URI变量提供URLs时，此行为可能会引起混乱。考虑以下两个URL：

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

在前一种情况下，URL被传递到不了解“ git”的wget提取程序。因此，后一种情况是正确的形式，因为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:// mapping展示的那样。

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

文件完整性对于可复现的构建至关重要。对于非本地档案下载，提取程序可以验证SHA-256和MD5校验和，以确保档案已正确下载。您可以通过将SRC_URI变量与相应的varflags一起使用来指定这些校验和，如下所示：

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

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

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

如果存在多个URIs，则可以像上一个示例一样直接指定校验和，也可以命名这些URLs。以下语法展示了如何命名URI：

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

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

注意
假定本地存储可以防止数据损坏。如果不是这种情况，将有更大的问题要担心。

如果设置了BB_STRICT_CHECKSUM，则没有校验和的任何下载都会触发错误消息。 BB_NO_NETWORK变量可用于使任何尝试的网络访问成为致命错误，这对于检查镜像是否像其他内容一样完整很有用。

4.2 解压(Unpack)

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

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

unpack：控制是否对URL组件进行解压缩。如果设置为默认值“ 1”，则会解压该组件。如果设置为“ 0”，则解压缩阶段将不处理该文件。当您要复制归档文件而不将其解压缩时，此参数很有用。
dos：适用于.zip和.jar文件，并指定是否对文本文件使用DOS行尾转换。
basepath：指示解压缩阶段在解压缩时从源路径中剥离指定的目录。
subdir：将特定的URL解压缩到根目录中的指定子目录。

解压缩调用会自动解压缩并提取带有“ .Z”，“.z”，“.gz”，“.xz”，“.zip”，“.jar”，“.ipk”，“.rpm”, “ .srpm”，“.deb”和“ .bz2”扩展名的文件。

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

4.3 抓取器(Fetches)

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

4.3.1 本地文件抓取(files://)

该子模块处理以file：//开头的URL。您在URL中指定的文件名可以是文件的绝对路径或相对路径。如果文件名是相对的，则FILESPATH变量的内容的使用方式与PATH查找可执行文件的方式相同。如果找不到该文件，则假定在调用download()方法时由DL_DIR指定。

以下是几个示例URL，第一个相对URL和第二个绝对URL：

SRC_URI =“ file://relativefile.patch”
SRC_URI =“ file:///Users/ich/very_important_software”

4.3.2 HTTP/FTP的wget抓取(http:// ftp:// https://)

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

使用的可执行文件和参数由FETCHCMD_wget变量指定，该变量默认为合理(sensible)的值。提取程序支持参数“ 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：//you@oe.handhelds.org/home/you/secret.plan”

说明：
由于URL参数由分号分隔，因此在解析包含分号的URL时，这可能会引起歧义，例如：
SRC_URI =“ http://abc123.org/git/?p=gcc/gcc.git;a=快照;h = a5dd47”
应该通过用’＆‘字符代替分号来修改此类URL：
SRC_URI =“ http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47”
在大多数情况下，这应该可行。万维网联盟（W3C）建议对查询中的分号和’＆'进行相同处理。请注意，由于URL的性质，您可能还必须指定下载文件的名称：
SRC_URI =“ http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47;downloadfilename=myfile.bz2”

4.3.3 CVS抓取(cvs://)

该子模块负责从CVS版本控制系统中检出文件。您可以使用许多不同的变量来配置它：

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

除了标准的用户名和密码URL语法外，您还可以使用各种URL参数配置提取程序：
支持的参数如下：

“method”：与CVS服务器进行通信的协议。默认情况下，此协议为“ pserver”。如果将“方法”设置为“ext”，则BitBake将检查“ rsh”参数并设置CVS_RSH。对本地目录，可以使用“ dir”。
“module”：指定要检出的模块。您必须提供此参数。
“tag”：描述应将哪个CVS TAG用于结帐。默认情况下，TAG为空。
“date”：指定日期。如果未指定“日期”，则使用配置的SRCDATE签出特定日期。 “ now”的特殊值使checkout在每个构建中更新。
“localdir”：用于重命名模块。实际上，您将重命名模块解压缩到的输出目录。您将强制将模块解压到相对于CVSDIR的指定目录。
“rsh”：与“ method”参数一起使用。
“scmdata”：设置为“ keep”时导致CVS元数据在在提取程序创建的压缩包中得以维护。压缩包将展开到工作目录中。默认情况下，将删除CVS元数据。
“fullpath”：控制结果检出是在模块级别（默认值）还是在更深的路径。
“norecurse”：使访存程序仅检出指定目录，而不会递归到任何子目录中。
“port”：CVS服务器连接到的端口。

一些示例URL如下：

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

4.3.4 SVN抓取(svn://)

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

支持的参数如下：

“module”：要签出的svn模块的名称。您必须提供此参数。您可以将该参数视为所需存储库数据的顶层目录。
“path_spec”：用来检出指定的svn模块的特定目录。
“protocol”：使用的协议，默认为“ svn”。如果将“协议”设置为“ svn + ssh”，则还将使用“ ssh”参数。
“rev”：要签出的源代码的修订版。
“scmdata”：设置为“ keep”时，导致“.svn”目录在编译期间可用。默认情况下，将删除这些目录。
“ssh”：当“协议”设置为“ svn + ssh”时使用的可选参数。您可以使用此参数来指定svn使用的ssh程序。
“transportuser”：必要时，设置传输的用户名。默认情况下，此参数为空。传输用户名不同于传递给subversion命令的主URL中使用的用户名。

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

SRC_URI =“ svn：// myrepos / proj1; module = vip; protocol = http; rev = 667”
SRC_URI =“ svn：// myrepos / proj1; module = opie; protocol = svn + ssh”
SRC_URI =“ svn：// myrepos / proj1; module = trunk; protocol = http; path_spec = $ {MY_DIR} / proj1”

4.3.5 Git抓取(git://)

该提取程序子模块从Git源代码控制系统提取代码。提取程序通过将远端代码库裸克隆到GITDIR（通常为DL_DIR / git2）来工作。然后，在checkout特定树时，在解压缩阶段将此代码库克隆到工作目录中。这是通过使用备用方法（通过引用）来完成的，以最大程度地减少磁盘上的重复数据量并加快解压缩过程。可以使用FETCHCMD_git设置所使用的可执行文件。

此提取程序支持以下参数：

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

以下是一些示例URL：

SRC_URI =“ git：//git.oe.handhelds.org/git/vip.git; tag = version-1”
SRC_URI =“ git：//git.oe.handhelds.org/git/vip.git; protocol = http”

4.3.6 Git子模块抓取(gitsm://)

此提取程序子模块继承自Git提取程序(git fetcher)，并通过访存代码库的子模块扩展了提取程序的功能。如4.3.5部分中所述，将SRC_URI传递到Git Fetcher。

注意和警告
在“ git：//”和“ gitsm：//” URL之间切换时，必须清理配方。
Git子模块提取程序不是完整的提取程序实现。提取程序在未正确使用常规源镜像基础结构的地方存在已知问题。此外，许可和源归档基础结构看不到它获取的子模块源。

4.3.7 ClearCase抓取(ccrc://)

此抓取程序子模块从ClearCase存储库中获取代码。

要使用此提取程序，请确保您的配方具有正确的SRC_URI，SRCREV和PV设置。如：

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

提取程序使用rcleartool或cleartool远程客户端，具体取决于可用的客户端。

以下是SRC_URI语句的选项：

vob：ClearCase VOB的名称，必须包含前置的“ /”字符。此选项是必需的。
module：所选VOB中的模块，必须包含前置的“ /”字符。

注意
模块和VOB选项组合在一起，以在视图配置规范中创建加载规则。例如，请考虑本节开头的SRC_URI语句中的vob和module值。合并这些值将得到以下结果：
`load /example_vob/example_module·
proto：协议，可以是http或https。

默认情况下，提取程序创建一个配置规范。如果要将此规范写入默认区域以外的区域，请在配方中使用CCASE_CUSTOM_CONFIG_SPEC变量来定义规范的写入位置。

注意
如果指定此变量，SRCREV将失去其功能。但是，即使提取未定义SRCREV，SRCREV仍用于在提取后标记存档。

以下是一些值得一提的其他行为：

使用cleartool时，cleartool的登录由系统处理。登录无需任何特殊步骤。
为了将rcleartool与经过身份验证的用户一起使用，在使用访存程序之前，必须先进行“ rcleartool登录”。

4.3.8 Perforce抓取(p4://)

该提取程序子模块从Perforce源代码控制系统中提取代码。使用的可执行文件由FETCHCMD_p4指定，默认为“ p4”。提取程序的临时工作目录由P4DIR设置，默认为“DL_DIR/p4”。

要使用此提取程序，请确保您的配方具有正确的SRC_URI，SRCREV和PV值。如果您不希望在配方本身中保留这些值，则p4可执行文件可以使用系统的P4CONFIG环境变量定义的配置文件来定义Perforce服务器URL和端口，用户名和密码。如果选择不使用P4CONFIG或显式设置P4CONFIG可以包含的变量，则可以指定P4PORT值（即服务器的URL和端口号），并且可以直接在配方中的SRC_URI中指定用户名和密码。

以下是一个依赖P4CONFIG来指定服务器URL和端口，用户名和密码并获取Head版本的示例：

SRC_URI = "p4://example-depot/main/source/..."
SRCREV = "${AUTOREV}"
PV = "p4-${SRCPV}"
S = "${WORKDIR}/p4"

以下是一个指定服务器URL和端口，用户名和密码，并根据标签获取修订的实例：

    P4PORT = "tcp:p4server.example.net:1666"SRC_URI = "p4://user:passwd@example-depot/main/source/..."SRCREV = "release-1.0"PV = "p4-${SRCPV}"S = "${WORKDIR}/p4"

注意：
在配方中，应始终将S设置为“ $ {WORKDIR} / p4”。

4.3.9 Repo抓取(repo://)

此提取程序子模块从google-repo源代码控制系统中提取代码。提取程序通过将代码库初始化并同步到REPODIR（通常为DL_DIR/repo）中来工作。