Yocto - 使用Yocto开发嵌入式Linux系统

Grasping the BitBake Tool

在上一章中，我们了解了元数据、元数据集合概念以及 conf/layer.conf 的重要性。在本章中，我们将更深入地研究元数据，了解配方如何相互依赖，并了解 BitBake 如何处理依赖关系。

In the previous chapter, we learned about metadata, metadata collection concepts, and the importance of conf/layer.conf . In this chapter, we will examine metadata more deeply, understand how recipes depend on each other, and see how BitBake deals with dependencies.

此外，我们还将涵盖从下载源代码到生成映像和其他工件的大量任务。这些任务包括将源代码存储在用于构建的目录中、打补丁、配置、编译、安装和生成软件包，以及确定软件包如何与本章将介绍的生成映像相匹配。

In addition, we will cover a massive list of tasks, from downloading source code to generating images and other artifacts. Some examples of these tasks are storing the source code in the directory used for the build, patching, configuring, compiling, installing, and generating packages, and determining how the packages fit into the generated images, which we will introduce in this chapter.

1，Parsing metadata

通常，我们的项目包括多个层，这些层提供不同的元数据，以满足特定需求。例如，当我们使用source oe-init-build-env build 初始化构建目录时，会生成如下一组文件：

Usually, our projects include multiple layers that provide different metadata to fulfill specific needs. For example, when we initialize a build directory, using source oe-init-build-env build, a set of files is generated as follows:

[ Figure 5.1 – A list of files created with source oe-init-build-env build ]

build/conf/templateconf.cfg 文件指向用作创建 build/conf 目录模板的目录。

The build/conf/templateconf.cfg file points to the directory used as the template to create the build/conf directory.

注意

用户可以使用 TEMPLATECONF 环境变量提供不同的模板目录，例如 TEMPLATECONF=/some/dir source oe-init-build-env build。

Note

A user can provide a different template directory using the TEMPLATECONF environment variable – for example, TEMPLATECONF=/some/dir source oe-init-build-env build.

build/conf/local.conf 文件是本地配置的占位符。我们在第 2 章 “构建第一个基于 Poky 的系统 ”中使用了该文件，并将在本书中继续使用。

The build/conf/local.conf file is the placeholder for the local configurations. We used this file in Chapter 2, Baking Our First Poky-Based System, and we will use it throughout this book.

BitBake 使用 build/conf/bblayers.conf 文件列出构建环境中考虑的图层。示例如下：

BitBake uses the build/conf/bblayers.conf file to list the layers considered in the build environment. An example is as follows:

[ Figure 5.2 – The build/conf/bblayer.conf content after the source oe-init-build-env build ]

第 8 行的 BBLAYERS 变量是一个用空格分隔的图层目录列表。BitBake 会解析每个图层，将其内容加载到元数据集合中。BitBake 使用的元数据可分为三大类。具体如下

The BBLAYERS variable, on line 8, is a space-delimited list of layer directories. BitBake parses each layer to load its content to the metadata collection. There are three major categories that the metadata used by BitBake can be classified into. They are listed as follows:

* Configuration (the .conf files)

* Classes (the .bbclass files)

* Recipes (the .bb and .bbappend files)

Tip

BitBake 在解析元数据时，会按照从左到右的顺序使用 BBLAYERS 变量中列出的图层。因此，如果你的图层需要优先解析，请将其列在 BBLAYERS 变量的正确位置。

The order of the listed layers in the BBLAYERS variable is followed from left to right by BitBake when parsing the metadata. Therefore, if your layer needs to be parsed first, have it listed in the right place in the BBLAYERS variable.

解析完所有可用图层后，BitBake 开始解析元数据。BitBake 首先解析的元数据是配置元数据，以 .conf 文件扩展名标识。这种元数据是全局性的，因此会影响所有已执行的配方和任务。

After parsing all the layers in use, BitBake starts to parse the metadata. The first parsed metadata in BitBake is configuration metadata, identified by the .conf file extension. This metadata is global and, therefore, affects all executed recipes and tasks.

Note

配置文件的一个典型例子是机器文件，它包含一个描述硬件的设置列表。

One typical example of the configuration file is the machine file, which has a list of settings that describes the hardware.

BitBake 首先从 BBPATH 列表中包含的路径之一加载 meta/conf/bitbake.conf。 meta/conf/bitbake.conf 文件使用 include 指令调入元数据，如特定架构元数据、机器配置文件和 build/conf/local.conf 文件。BitBake 配置文件（.conf）的一个重要限制是只允许使用变量定义和 include 指令。

BitBake first loads meta/conf/bitbake.conf from one of the paths included in the BBPATH list. The meta/conf/bitbake.conf file uses include directives to pull in metadata, such as architecture-specific metadata, machine configuration files, and the build/conf/local.conf file. One significant restriction of BitBake configuration files (.conf) is that only variable definitions and include directives are allowed.

BitBake 的类（ .bbclass）是 classes/ 目录中最基本的继承机制。当解析过程中出现继承指令时，BitBake 会立即解析链接的类。类的内容会根据 BBPATH 变量列表的顺序进行搜索。

BitBake’s classes (.bbclass) are a rudimentary inheritance mechanism in the classes/ directories. When an inherit directive appears during parsing, BitBake immediately parses the linked class. The class content is searched based on the order of the BBPATH variable list.

BBFILES 变量是以空格分隔的 .bb 和 .bbappend 文件列表，可以使用通配符。conf/layer.conf 中的每一层都需要使用该变量，这样 BitBake 才能知道在哪里查找配方。BitBake 配方（.bb）是要执行的任务的逻辑单元；通常指一个软件包。

The BBFILES variable is a space-separated list of the .bb and .bbappend files and can use wildcards. It is required in every layer inside conf/layer.conf, so BitBake knows where to look for recipes. A BitBake recipe (.bb) is a logical unit of tasks to be executed; typically, it refers to a package.

2，Dependencies

从 BitBake 的角度来看，有三种不同的依赖类型：

From the BitBake point of view, there are three different dependency types:

* Build time

* Execution time

* Tasks

应用程序如果需要其他软件包（如库），则成功编译就有一个联编依赖。联编依赖包括编译器、库和本地联编工具（如 CMake）。此外，只要应用程序只在执行时才需要，联编依赖关系就具有执行依赖关系。运行时依赖项包括字体、图标、动态打开的库和语言解释器。

An application that needs some other package, such as a library, has a build dependency for a successful compilation. Build dependencies include compilers, libraries, and native build tools (such as CMake). In addition, a build dependency has an execution dependency whenever an application is needed only during execution time. Runtime dependencies include fonts, icons, dynamically opened libraries, and language interpreters.

Tip

Poky 的惯例是在配方名称中使用 -native 后缀。这是因为这些工具的目的是在构建过程中在主机构建系统中运行，而不是部署到目标中。

The convention inside Poky is to use -native suffixes for recipe names. This is because those tools are aimed to be run during the build process, in the host building system, and are not deployed into the target.

任务依赖关系为混乱的任务执行创造了秩序，例如，要编译一个软件包，就需要下载源代码。在表面下，所有的依赖关系都是任务依赖关系。这意味着，当软件包 B 在构建时依赖于软件包 A 时，软件包 A 的任务需要在软件包 B 启动前完成。

The task dependencies create order in the chaos of task execution – for example, to compile a package, the source code needs to be downloaded. Under the hood, all the dependencies are task dependencies. This means that when package B has a build-time dependency on package A, the tasks from package A need to be completed before package B starts.

元数据表示所有依赖关系。OpenEmbedded Core 提供了大量类来处理常用的默认任务依赖关系，例如，一个配方可以用 DEPENDS 变量来表达构建时依赖关系，用 RDEPENDS 变量来表达执行时依赖关系。

Metadata expresses all the dependencies. OpenEmbedded Core provides a vast set of classes to handle the default task dependencies commonly used – for example, a recipe can express a build-time dependency with the DEPENDS variable and an execution-time dependence with the RDEPENDS variable.

了解了配方依赖链，BitBake 就能按照可行的顺序排列构建过程中的所有配方。BitBake 可通过以下方式组织任务：

Knowing the recipe dependencies chain, BitBake can sort all the recipes for the build in a feasible order. BitBake organizes tasks in the following ways:

* 没有依赖关系的配方任务并行构建

* 以串行顺序构建依赖配方，并以满足依赖关系的方式进行排序

* Recipe tasks that do not have a dependency relation are built in parallel

* Dependent recipes are built in serial order and sorted in a way that satisfies the dependencies

Tip

运行时依赖项中包含的每个配方都会被添加到联编列表中。这听起来很明显，但即使它们在构建过程中不起作用，它们也需要准备就绪以便使用，这样生成的二进制包才可以安装。在构建映像或生成组件时就需要这样做。

Every recipe included in the runtime dependencies is added to the build list. This sounds obvious, but even though they have no role during the build, they need to be ready for use so that the resulting binary packages are installable. This will be required when building images or populating feeds.

3，Preferring and providing recipes

依赖关系是两个事物之间的一种关系；只有当另一方存在时，其中一方才能满足条件。不过，依赖关系只说明需要实现某些功能或特性，而不确切说明必须如何实现。

Dependency is a relation between two things; one side can only be fulfilled if the other side exists. However, a dependency only specifies that some functionality or characteristic is needed to be fulfilled, not precisely how it must be fulfilled.

例如，当一个配方依赖于 A 时，人们首先想到的是它依赖于一个名为 A 的配方。然而，有两种可能的方法可以满足 A 的依赖性要求：

For example, when a recipe depends on A, the first thought is that it depends on a recipe called A. However, there are two possible ways to satisfy the dependency requirement of A:

* 名为 A 的配方

* 提供名为 A 的功能或特性的配方

* A recipe called A

* A recipe that provides a functionality or characteristic called A

配方若要向 BitBake 表明它能满足功能或特性要求，就必须使用 PROVIDES 关键字。一个微妙的结果是，两个或多个配方可以提供相同的功能或特性。我们必须使用 PREFERRED_PROVIDER 关键字告知 BitBake 哪个配方能满足该要求。

For a recipe to communicate to BitBake that it can fulfill a functionality or characteristic requirement, it must use the PROVIDES keyword. A subtle consequence is that two or more recipes can deliver the same functionality or characteristic. We must inform BitBake which recipe should fulfill that requirement using the PREFERRED_PROVIDER keyword.

因此，如果名为 foo_1.0.bb 的配方依赖于 bar，BitBake 就会列出所有提供 bar 的配方。bar 依赖关系可通过以下方式实现：

So, if a recipe called foo_1.0.bb depends on bar, BitBake lists all recipes providing bar. The bar dependency can be satisfied by the following:

* 采用 bar_<version>.bb 格式的配方，因为默认情况下每个配方都会提供自己同名的内容

* PROVIDES 变量包含 bar 的配方

* A recipe with the bar_<version>.bb format because every recipe provides itself by default

* A recipe where the PROVIDES variable includes bar

virtual/kernel provider就是这种机制的一个明显例子。virtual/ 命名空间是我们在拥有一组常用重载提供程序时采用的约定。

The virtual/kernel provider is a clear example of this mechanism. The virtual/ namespace is the convention adopted when we have a set of commonly overridden providers.

所有需要构建内核的配方都可以将 virtual/kernel 添加到依赖列表 (DEPENDS)，然后 BitBake 就会满足该依赖。当我们有多个配方需要替代提供者时，我们必须选择其中一个来使用，例如下面的情况：

All recipes that require the kernel to be built can add virtual/kernel to the dependency list ( DEPENDS), and BitBake satisfies the dependency. When we have more than one recipe with an alternative provider, we must choose one to be used – for example, the following:

[ Figure 5.3 – An example of how to set a preferred provider for virtual/kernel ]

virtual/kernel provider通常是在机器定义文件中设置的，因为它可能因机器而异。我们将在第 12 章 “创建自定义层 ”中了解如何创建机器定义文件。

The virtual/kernel provider is commonly set in the machine definition file, as it can vary from machine to machine. We will see how to create a machine definition file in Chapter 12, Creating Custom Layers.

Note

当由于缺少提供者而无法满足依赖关系时，BitBake 会引发错误。

BitBake raises an error when a dependency cannot be satisfied due to a missing provider.

当 BitBake 有两个不同版本的提供程序时，它默认使用最高版本。不过，我们可以通过使用 PREFERRED_VERSION 来强制 BitBake 使用不同的版本。这在 BSP（如引导加载程序）中很常见，因为供应商可能会为电路板使用特定的版本。

When BitBake has two providers with different versions, it uses the highest version by default. However, we can force BitBake to use a different version by using PREFERRED_VERSION. This is common in BSPs, such as bootloaders, where vendors may use specific versions for a board.

我们可以通过在配方文件中使用 DEFAULT_PREFERENCE 关键字来降低版本首选项，从而避免默认使用开发版或不可靠的配方版本，如下所示：

We can avoid using a development or an unreliable recipe version, by default, lowering the version preference by using the DEFAULT_PREFERENCE keyword in a recipe file, as follows:

[ Figure 5.4 – How to lower the version preference in a recipe ]

因此，即使版本更高，如果没有明确设置 PREFERRED_VERSION，也不会选择使用该配方。

So, even if the version is higher, the recipe is not choosen without PREFERRED_VERSION being explicitly set to use it.

4, Fetching the source code

下载 Poky 源代码时，我们会下载元数据集和 BitBake 工具。BitBake 支持的主要功能之一是获取额外的源代码。

When we download the Poky source code, we download the metadata collection and the BitBake tool. One of the main features supported by BitBake is additional source code fetching.

获取外部源代码的功能尽可能模块化和灵活。例如，每个基于 Linux 的系统都包含 Linux 内核和其他一些构成根文件系统的实用程序，如 OpenSSH 或 BusyBox。

The ability of fetching external source code is as modular and flexible as possible. For example, every Linux-based system includes the Linux kernel and several other utilities that form the root filesystem, such as OpenSSH or BusyBox.

OpenSSH 的源代码是以 HTTP 服务器托管的 tar.gz 文件形式从其上游网站上获取的，而 Linux 内核版本则在 Git 代码库中。因此，BitBake 可以轻松获取这两种不同的源代码实例。

The OpenSSH source code is available from its upstream website as a tar.gz file hosted on an HTTP server, while the Linux kernel release is in a Git repository. Therefore, BitBake can easily fetch those two different instances of source code.

BitBake 支持许多不同的获取模块，这些模块允许检索 tarball 文件和其他一些 SCM 系统，如以下系统：

BitBake offers support for many different fetcher modules that allow the retrieval of tarball files and several other SCM systems, such as the following:

* Amazon AWS S3

* Android repo

* Azure Storage

* Bazaar

* ClearCase

* CVS

* FTP

* Git

* Git Annex

* Git submodules

* HTTP(S)

* Mercurial

* NPM

* NPMSW (npm shrinkwrap implementation)

* openSUSE Build Service client

* Perforce

* Rust Crate

* SFTP

* SSH

* Subversion

BitBake 用于获取源代码的机制在内部称为 “获取器后端程序”，该程序可根据用户需求进行配置，并优化源代码的获取。

The mechanism used by BitBake to fetch the source code is internally called a fetcher backend, which is configurable to align a user’s requirements and optimize fetching the source code.

Remote file downloads

BitBake 支持多种远程文件下载方式。最常用的是 http://、https:// 和 git://。我们将不介绍 BitBake 如何处理远程文件下载的内部细节，而专注于它的可见效果。

BitBake supports several methods for remote file downloads. The most commonly used are http://, https://, and git://. We won’t cover the internal details of how BitBake handles remote file downloads and will instead focus on its visible effects.

当 BitBake 执行配方中的 do_fetch 任务时，它会检查 SRC_URI 的内容。例如，我们来看 pm-utils 配方（见 meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb）。处理后的变量如下图所示：

When BitBake executes the do_fetch task in a recipe, it checks the SRC_URI contents. Let’s look at, for example, the pm-utils recipe (available at meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb). The processed variables are shown in the following figure:

[ Figure 5.5 – SRC_URI for the pm-utils_1.4.1.bb recipe ]

BitBake 会将 PV 变量扩展为软件包版本（本例中是 1.4.1 取自 pm-utils_1.4.1.bb 配方文件名），以便从 http://pm-utils.freedesktop.org/releases/pm-utils-1.4.1.tar.gz 下载文件，然后将其保存到 DL_DIR，就是下载存储目录。

BitBake expands the PV variable to the package version ( 1.4.1 in this example is taken from the pm-utils_1.4.1.bb recipe filename) to download the file from http://pm-utils.freedesktop.org/releases/pm-utils-1.4.1.tar.gz , and then saves it as DL_DIR, which points to the download storage directory.

下载完成后，BitBake 会比较下载文件的 sha256sum 值和配方中的值。如果值匹配，它就会创建一个 ${DL_DIR}/pm-utils-1.4.1.tar.gz.done 文件，以标记该文件已成功下载并通过检查，从而允许 BitBake 重新使用它。

After the download is complete, BitBake compares the sha256sum value of the downloaded file with the value from the recipe. If the value matches, it creates a ${DL_DIR}/pm-utils-1.4.1.tar.gz.done file to mark the file as successfully downloaded and checked, allowing BitBake to reuse it.

Note

默认情况下，DL_DIR 变量指向 build/downloads。你可以在 build/conf/local.conf 文件中添加以下一行 - DL_DIR = “/my/download-cache”，从而覆盖该变量。这样，我们就可以在多个构建目录中共享同一个下载缓存，从而节省下载时间和带宽。

By default, the DL_DIR variable points to build/downloads. You can override this by adding to the build/conf/local.conf file the following line – DL_DIR = "/my/download-cache". Using this, we can share the same download cache among several build directories, thus saving download time and bandwidth.

Git repositories

Git 是最常用的源代码控制系统之一。BitBake 为 Git 提供了坚实的支持，在运行 do_fetch 任务并在 SRC_URI 变量开头找到 git:// URL 时，就会使用 Git 后端。

One of the most commonly used source control management systems is Git. BitBake has solid support for Git, and the Git backend is used when the do_fetch task is run and finds a git:// URL at the beginning of the SRC_URI variable.

BitBake 的 Git 后台处理版本库的默认方式是克隆到 ${DL_DIR}/git2/<git URL> 中--例如，请查看 Poky 内 meta/recipes-support/lz4/lz4_1.9.4.bb 中 lz4_1.9.4.bb 配方的以下引用：

The default way for BitBake’s Git backend to handle the repositories is to clone the repository in ${DL_DIR}/git2/<git URL> – for example, check the following quote from the lz4_1.9.4.bb recipe found in meta/recipes-support/lz4/lz4_1.9.4.bb inside Poky:

[ Figure 5.6 – Source code download configuration for the lz4_1.9.4.bb recipe ]

这里，lz4.git 仓库被克隆到 ${DL_DIR}/git2/ github.com.lz4.lz4.git。这个目录名避免了项目名称相同的 Git 仓库之间的冲突。

Here, the lz4.git repository is cloned in ${DL_DIR}/git2/ github.com.lz4.lz4.git. This directory name avoids conflicts between possible Git repositories with the same project name.

git2 文件夹的名称主要是指第二代获取器（Git 协议版本 2），而不是 Yocto 用来处理 Git 仓库的旧方法。这是 Yocto 获取和缓存版本库的内部版本系统的一部分。

* git：指旧版本的实现。

* git2: 指当前或更现代的 Git 抓取实现。

The git2 folder name essentially refers to the second-generation fetcher (Git protocol version 2), as opposed to the older way Yocto used to handle Git repositories. This is part of an internal versioning system for how Yocto fetches and caches repositories.

* git: Refers to older implementations.

* git2: Refers to the current or more modern implementation for Git fetcher.

SRCREV 变量有两种影响情况。具体如下:

There are two cases where the SRCREV variable has an impact. They are as follows:

* do_fetch：该任务使用 SRCREV 变量确保版本库中有所需的 Git 修订版本

* do_unpack：该任务使用 SRCREV 设置工作目录，并提供必要的源代码修订版本

* do_fetch: This task uses the SRCREV variable to ensure the repository has the required Git revision

* do_unpack: This task uses SRCREV to set up the working directory with the necessary source revision

Note

我们需要使用 branch=<branch name> 参数，如下所示 - SRC_URI = “ git://myserver/myrepo.git;branch=mybranch” - 来指定包含我们要使用的修订版本的分支。如果使用的哈希值指向的标签在某个分支上不可用，我们需要使用 nobranch=1 选项，如下所示 - SRC_URI = “ git://myserver/myrepo.git;nobranch=1”。

We need to use the branch=<branch name> parameter as follows – SRC_URI = "git://myserver/myrepo.git;branch=mybranch" – to specify the branch that contains the revision we want to use. In cases when the hash used points to a tag that is not available on a branch, we need to use the nobranch=1 option as follows – SRC_URI = "git://myserver/myrepo.git;nobranch=1".

远程文件和 Git 仓库是 BitBake 最常用的获取后端。其他支持源代码管理的系统在实现方式上各有不同，但总体思路和概念是相同的。

The remote file and the Git repository are the most commonly used fetch backends of BitBake. The other source code management-supported systems vary in their implementations, but the general ideas and concepts are the same.

5, Optimizing the source code download

为了提高源代码下载的稳健性，Poky 提供了一个镜像机制，可以提供以下功能：

To improve the robustness of source code download, Poky provides a mirror mechanism that can provide the following:

* 中央首选下载服务器

* 一组备用服务器

* A centrally preferred server for download

* A set of fallback servers

为了提供这种强大的下载机制，BitBake 遵循定义好的逻辑步骤。在构建过程中，BitBake 的第一步是在本地下载目录（由 DL_DIR 指定）中搜索源代码。如果失败，下一步就是尝试 PREMIRRORS 变量定义的位置。最后，BitBake 会在失败情况下搜索 MIRRORS 变量中指定的位置。总之，这些步骤如下：

To provide this robust download mechanism, BitBake follows defined logic steps. During the build, the first BitBake step is to search for the source code within the local download directory (specified by DL_DIR). If this fails, the next step is to try the locations defined by the PREMIRRORS variable. Finally, BitBake searches the locations specified in the MIRRORS variable in a failure case. In summary, these steps are as follows:

1. DL_DIR：在主机上查找已下载内容。

2. MIRRORS：在镜像列表中搜索需下载项。

3. PREMIRRORS：用于减少从外部服务器的下载，通常在公司内部使用，以减少或禁止互联网使用。

1. DL_DIR: Look for the download on the host machine.

2. MIRRORS: Search for the download in a list of mirrors.

3. PREMIRRORS: This is used to reduce the download from external servers and is usually used inside companies to reduce or forbid internet use.

实际顺序：

1, DL_DIR (Local Cache)

2, PREMIRRORS (Preferred Mirrors)

3, SRC_URI (Original Upstream Source)

4, MIRRORS (Fallback Mirrors)

例如，在将本地服务器 https://mylocalserver 配置为 PREMIRROR 时，我们可以在全局配置文件（如 build/conf/local.conf）中添加以下代码：

For example, when configuring a local server, https://mylocalserver, as PREMIRROR, we can add the following code to a global configuration file, such as build/conf/local.conf:

[ Figure 5.7 – An example of the PREMIRRORS configuration ]

前面的代码将 PREMIRRORS 变量预置为更改，并指示构建系统拦截任何下载请求。它将这些请求重定向到 https://mylocalserver 源代码的镜像。

The preceding code prepends the PREMIRRORS variable to change and instructs the build system to intercept any download requests. It redirects them to the https://mylocalserver source’s mirror.

PREMIRRORS 的使用非常普遍，因此有一个类来帮助配置。为了方便起见，我们可以继承 own-mirror 类，然后在任何全局配置文件（如 build/conf/local.conf）中将 SOURCE_MIRROR_URL 变量设置为 https://mylocalserver。

This use of PREMIRRORS is so common that there is a class to help its configuration. To make it easier, we inherit the own-mirror class and then set the SOURCE_MIRROR_URL variable to https://mylocalserver in any global configuration file, such as build/conf/local.conf.

[ Figure 5.8 – How to configure own-mirror ]

如果源镜像中没有所需的组件，BitBake 就会返回到 MIRRORS 变量。下图是该变量内容的示例。它显示了 mirrors.bbclass 中使用的一些服务器，Poky 默认继承了这些服务器：

If the desired component is unavailable in the source mirror, BitBake falls back to the MIRRORS variable. An example of the content of this variable is shown in the following figure. It shows some servers used in mirrors.bbclass, inherited by default in Poky:

[ Figure 5.9 – An example of how to use the MIRRORS variable ]

Tip

假设目标是建立一个可共享的下载缓存。在这种情况下，建议在 build/conf/local.conf 中使能 BB_GENERATE_MIRROR_TARBALLS = “1”，为下载文件夹中的 SCM 后端（例如 Git）启用生成压缩包功能。

Let’s suppose the goal is to have a shareable download cache. In that case, it is advisable to enable the tarball generation for the SCM backends (for example, Git) in the download folder with BB_GENERATE_MIRROR_TARBALLS = "1" in build/conf/local.conf.

Disabling network access

有时，我们需要确保在构建过程中不连接互联网。这样做有几个合理的原因，例如以下原因：

Sometimes, we need to ensure that we don’t connect to the internet during the build process. There are several valid reasons for this, such as the following:

* 政策：我们公司不允许在未经适当法律验证和审查的情况下在产品中加入外部资源。

* 网络成本：当我们使用移动宽带时，数据成本可能会过高，因为需要下载的数据可能会很多。

* 下载与构建解耦：这种设置在持续集成环境中非常典型，在这种环境中，一个作业负责下载所有需要的源代码。与此相反，构建任务则禁止互联网访问。下载和构建之间的解耦可确保不重复下载源代码，并缓存所有必要的源代码。

* 缺乏网络访问：有时，我们无法访问网络。

* Policy: Our company does not allow the inclusion of external sources in a product without proper legal validation and review.

* Network cost: When we are on the road using mobile broadband, the cost of data may be too high because the data to download may be extensive.

* Download and build decoupling: This setup is typical in continuous integration environments, where a job is responsible for downloading all the required source code. In contrast, the build jobs have internet access disabled. The decoupling between downloading and building ensures that no source code is downloaded in duplication and that we have cached all the necessary source code.

* Lack of network access: Sometimes, we do not have access to a network.

要禁用网络连接，我们需要在 build/conf/local.conf 文件中添加以下代码：

To disable the network connection, we need to add the following code in the build/conf/local.conf file:

[ Figure 5.10 – How to disable network access during the build ]

6, Understanding BitBake’s tasks

BitBake 使用执行单元，其实就是一组按顺序运行的指令集群。这些单元被称为任务。在每个配方的构建过程中，BitBake 会调度、执行和检查许多由类提供的任务，从而形成我们用于构建配方的框架。因此，我们有必要了解其中的一些任务，因为在编写配方时，我们经常会自己使用、扩展、实现或替换这些任务。

BitBake uses execution units, which are, in essence, a set of clustered instructions that run in sequence. These units are known as tasks. During every recipe’s build, BitBake, schedules, executes, and checks many tasks provided by classes to form the framework we use to build a recipe. Therefore, it is essential to understand some of these, as we often use, extend, implement, or replace them ourselves when writing a recipe.

当我们运行以下命令时，BitBake 会运行一组计划任务：

When we run the following command, BitBake runs a set of scheduled tasks:

[ Figure 5.11 – How to run all tasks for a recipe ]

当我们希望运行一项特定任务时，可以使用以下命令：

When we wish to run a specific task, we can use the following command:

[ Figure 5.12 – How to run a particular task for a recipe ]

要列出为配方定义的任务，我们可以使用以下命令：

To list the tasks defined for a recipe, we can use the following command:

[ Figure 5.13 – How to list all tasks for a recipe ]

wget 配方的 listtasks 输出如下：

The output of listtasks for the wget recipe is as follows:

[ Figure 5.14 – The list of tasks for the wget recipe ]

我们将在此简要介绍最常用的任务：

We will briefly describe the most commonly used tasks here:

* do_fetch：构建配方的第一步是使用获取后端功能获取所需的源代码，本章前面已经讨论过这一功能。需要注意的是，获取源代码或文件并不意味着它是远程源代码。

* do_unpack：do_fetch 任务之后的自然任务是 do_unpack。如果引用的源代码使用 SCM 系统，该任务负责解压缩源代码或检出请求的修订版或分支。

* do_patch：一旦源代码被正确解包，BitBake 就会开始调整源代码。do_fetch 抓取的每个文件，如果扩展名为 .patch，都会被假定为需要应用的补丁。该任务将应用所需的补丁列表。最终修改后的源代码将用于构建软件包。

* do_configure、do_compile 和 do_install： do_configure、do_compile 和 do_install 任务按此顺序执行。需要注意的是，不同任务中定义的环境变量是不同的。Poky 在类中提供了丰富的预定义任务，我们应该尽可能使用这些任务，例如，当配方继承 autotools 类时，它提供了 do_configure、do_compile 和 do_install 任务的已知实现。

* do_package： do_package 任务将配方安装的文件分割成逻辑组件，如调试符号、文档和库。我们将在第 7 章 “理解软件包支持”中更深入地介绍打包细节。

* do_fetch: The first step when building a recipe is fetching the required source using the fetching backends feature, which we discussed previously in this chapter. It is essential to note that fetching a source or a file does not mean it is a remote source.

* do_unpack: The subsequent natural task after the do_fetch task is do_unpack. This is responsible for unpacking source code or checking out the requested revision or branch in case the referenced source uses an SCM system.

* do_patch: Once the source code is properly unpacked, BitBake initiates adapting the source code. Every file fetched by do_fetch, with the .patch extension, is assumed to be a patch to be applied. This task applies the list of patches needed. The final modified source code will be used to build the package.

* do_configure, do_compile, and do_install: The do_configure, do_compile, and do_install tasks are performed in this order. It is important to note that the environment variables defined in the tasks are different from one task to another. Poky provides a rich collection of predefined tasks in the classes, which we ought to use when possible – for example, when a recipe inherits the autotools class, it provides a known implementation of the do_configure, do_compile, and do_install tasks.

* do_package: The do_package task splits the files installed by the recipe into logical components, such as debugging symbols, documentation, and libraries. We will cover packaging details in more depth in Chapter 7, Assimilating Package Support.

7, Summary

在本章中，我们了解了配方如何相互依赖，以及 Poky 如何处理依赖关系。我们还了解了如何配置下载以及如何优化下载。此外，我们还更好地了解了 BitBake 所管理的下载所有所需源代码并用于构建和生成软件包的任务。

In this chapter, we learned how recipes depend on each other and how Poky deals with dependencies. We understood how a download is configured and how to optimize it. In addition, we got a better view of the tasks managed by BitBake to download all the required source code and use it to build and generate packages.

在下一章中，我们将看到镜像生成完成后构建目录的内容，并了解 BitBake 如何在烘焙过程中使用它，包括临时构建目录的内容及其生成的文件。

In the next chapter, we will see the contents of the build directory after complete image generation and learn how BitBake uses it in the baking process, including the contents of the temporary build directory and its generated files.