4.2层layer

层是包含相关元数据（即一组指令）的存储库，可告诉 OpenEmbedd 构建系统如何构建目标。 Yocto 项目层模型可促进 Yocto 项目开发环境中的合作、共享、定制和再利用。从逻辑上讲，为您的项目划分信息层。例如，您可以使用一层来保留特定硬件的所有配置。隔离特定于硬件的配置允许您使用不同的层来共享其他元数据，其中元数据在几个硬件中可能很常见。

在 Yocto 项目开发环境中有许多层工作。Yocto 项目策划层索引和开放式层索引都包含您可以使用或利用的层。

按照惯例，Yocto 项目的层遵循特定形式。符合已知结构允许 BitBake 在构建到查找元数据类型时做出假设。您可以在《Yocto 项目开发任务手册》的"理解和创建层"部分找到创建适合 Yocto 项目的图层的程序并了解工具（即）。bitbake-layers

注意

Poky 存储库主要是现有存储库的聚合。它不是一个规范的上游来源。

注意

scripts/oe-setup-builddir script 使用变量来确定要定位的示例配置文件。

$TEMPLATECONF

注意

在 conf/local.conf 文件中设置的配置也可以设置在conf/site.conf 和conf/site.conf  配置文件中。

该文件告诉 BitBake 您希望在构建过程中考虑哪些层。默认情况下，此文件中列出的图层包括构建系统最不需要的层。但是，您必须手动添加您创建的任何自定义图层。您可以在 Yocto 项目开发任务手册中的"‎‎启用您的层‎‎"部分找到有关与文件合作的更多信息。‎bblayers.confbblayers.conf

‎文件不是由环境初始化脚本创建的。如果你想要的文件，你需要自己创建。该文件通常由自动建设者创建：‎

site.conf

auto.conf

site.conf

auto.conf

• ‎site.conf: ：‎‎您可以使用配置文件配置多个构建目录。例如，假设您有几个构建环境，它们具有一些共同的功能。您可以在此处设置这些默认构建属性。一个很好的例子也许是通过‎‎PACKAGE_CLASSES‎‎变量使用的包装格式。‎conf/site.conf

  ‎使用该文件的一个有用的方案是扩展您的‎‎BBPATH‎‎变量，包括路径到。然后，当 BitBake 使用‎‎BBPATH‎‎查找元数据时，它会找到该文件并应用文件中常见的配置。要覆盖特定构建目录中的配置，要更改该构建目录文件中的类似配置。‎conf/site.confconf/site.confconf/site.confconf/local.conf

• ‎auto.conf:：‎‎该文件通常由自动建设者创建并写入。放入文件的设置通常与在文件或文件中找到的设置相同。‎conf/local.confconf/site.conf

‎您可以编辑所有配置文件以进一步定义任何特定的构建环境。此过程由图中的"用户配置编辑"框表示。‎

‎当您使用命令启动构建时，BitBake 会整理出配置，以最终定义构建环境。重要的是要了解，‎‎开放式构建系统‎‎以特定顺序读取配置文件：并且，构建系统应用 BitBake 用户手册中的"‎‎语法和操作员‎‎"章节中描述的正常分配语句规则。由于文件按特定顺序解析，因此可能会影响同一变量的可变分配。例如，如果文件和设置的变量 1 到不同的值，因为构建系统解析后，可变 1 被分配从文件中的值。

‎bitbake targetsite.conf

auto.conf

local.confa

uto.conf

local.conf

local.conf

auto.conf

local.conf

4.3.2.2BSP 层

BSP 层提供针对特定硬件的机器配置。此层中的一切特定于您正在构建图像或 SDK 的机器。BSP 层定义了一个通用结构或形式。您可以在Yocto 项目委员会支持包开发人员指南中了解更多有关此结构的详细情况。

BSP 层的配置目录包含机器（）的配置文件，当然还有该层（）。conf/machine/machine.confconf/layer.conf

层的其余部分是专门按功能特定的食谱：，，，等等。可以有多个外形器、图形支持系统等的元数据。recipes-bsprecipes-corerecipes-graphicsrecipes-kernel

4.3.2.3软件层

软件层为构建过程中使用的其他软件包提供元数据。此层不包括特定于分布或机器的元数据，这些元数据位于其各自的层中。

此层包含项目所需的任何配方、附加文件和修补程序。

4.3.3.1上游项目发布

上游项目版本以存档文件（例如焦油球或拉链文件）的形式存在于任何地方。这些文件对应于单个食谱。例如，该图使用"忙碌盒"、Qt 和 Dbus 的每个版本。存档文件可用于使用配方构建的任何已发布的产品。

4.3.3.2本地项目

本地项目是用户提供的自定义软件位。这些位位于项目本地的某个地方 - 也许是用户检查项目（例如包含组使用的开发源树的本地目录）的目录。

包括本地项目的规范方法是使用外部src类来包括该本地项目。您使用或配方的附加文件来覆盖或设置配方指向磁盘上的本地目录以拉入整个源树。local.conf

4.3.3.3源控制经理（可选）

构建系统可以获取源文件的另一个地方是Fetchers使用各种源控制管理器 （SCM），如 Git 或颠覆。在这种情况下，存储库被克隆或检查出来。BitBake 内部的do_fetch任务使用SRC_URI变量和参数的前缀来确定正确的取件器模块。

取取存储库时，BitBake 使用SRCREV变量来确定构建的具体修订。

4.3.4包装馈送

当 OpenEmbedd 生成生成图像或 SDK 时，它会从位于构建目录中的包馈送区域获取包。一般工作流程图显示此包在右上角的馈送区域。

此部分看起来更接近构建系统使用的包源区域。以下是对该地区的更详细的了解：

do_fetch和do_unpack任务获取源文件，并将其解包到生成目录中。

默认情况下，所有内容都以具有定义结构的构建目录完成。有关构建目录的其他一般信息，请参阅 Yocto 项目参考手册中的"构建/"部分。

每个配方在构建目录中都有一个区域，未包装的源代码就位于该区域。 S变量指向此区域，用于配方的未包装源代码。任何给定配方的目录名称是从几个不同的变量定义的。上一个数字和以下列表描述了构建目录的层次结构：

• TMPDIR：开放式构建系统在构建过程中执行所有工作的基础目录。默认基础目录是目录。tmp

• PACKAGE_ARCH：已构建的包或封装的架构。根据包或包的最终目的地（即机器架构、构建主机、SDK 或特定机器），PACKAGE_ARCH会有所不同。有关详细信息，请参阅该变量的描述。

• TARGET_OS：目标设备的操作系统。典型的值是"linux"（例如"qemux86-poky-linux"）。

• PN：用于构建包装的配方名称。此变量具有多种含义。但是，在输入文件上下文中使用时，PN表示配方的名称。

• WORKDIR:：开放式构建系统构建配方的位置（即创建包的工作）。

  • PV:：用于构建包装的配方版本。

  • PR：用于构建包装的配方的修订。

• S： 包含给定配方的未包装源文件。

  • BPN：用于构建包装的配方名称。 BPN变量是PN变量的一个版本，但删除了通用前缀和后缀。

  • PV：用于构建包装的配方版本。

4.3.5.2 Patching

‎取件并拆开源代码后，BitBake 会定位修补文件并将它们应用到源文件中：‎

‎

do_patch任务使用配方的SRC_URI语句和文件路径变量来定位适用的修补程序文件。

修补程序文件的默认处理假定文件有或文件类型。您可以使用SRC_URI参数更改构建系统识别修补程序文件的方式。有关更多信息，请参阅do_patch任务。*.patch*.diff

BitBake 发现并应用多个修补程序，用于单个配方，以它定位修补程序的顺序。文件路径变量定义了构建系统用于搜索修补程序文件的默认目录集。一旦发现，补丁将应用于位于S目录中的配方源文件。

有关源目录创建方式的更多信息，请参阅"源获取"部分。有关如何创建修补程序以及构建系统如何处理修补程序的更多信息，请参阅 Yocto 项目开发任务手册中的"修补代码"部分。您还可以在 Yocto 项目应用程序开发和扩展软件开发套件 （SDK） 手册中看到"使用开发工具修改以修改现有组件的来源"部分，以及 Yocto 项目 Linux 内核开发手册中的"使用传统内核开发来修补内核"部分。

4.3.5.3配置、编译和分期

源代码修补后，BitBake 执行配置和编译源代码的任务。一旦汇编发生，文件被复制到保留区域（阶段），为包装做准备：

‎ ‎‎do_package‎‎和‎‎do_packagedata‎‎任务相结合，分析‎‎D‎‎目录中的文件，并根据可用的软件包和文件将其拆分为子集。分析包括以下项目以及其他项目：拆分调试符号、查看包之间的共享库依赖关系以及查看包关系。‎

‎任务根据分析创建包元数据，以便构建系统可以生成最终包。‎‎ ‎‎do_populate_sysroot‎‎任务阶段（副本）‎‎将do_install‎‎任务安装的文件的子集放入适当的 ssroot 中。分析和包拆分过程的工作、分阶段和中间结果使用几个领域：‎do_packagedata

• ‎ ‎‎PKGD‎‎： 包裹被拆分为单独包之前的目的地目录（即）。‎package

• ‎ ‎‎PKGDESTWORK‎‎： 任务中用于保存包元数据的临时工作区域（ 即 ） 。‎pkgdatado_package

• ‎ ‎‎PKGDEST：‎‎包裹被拆分后的父目录（即）。‎packages-split

• ‎ ‎‎PKGDATA_DIR：‎‎一个共享的全球国家目录，保存包装过程中产生的包装元数据。包装过程将元数据从‎‎PKGDESTWORK‎‎复制到‎‎全球可用的PKGDATA_DIR‎‎区域。‎

• ‎ ‎‎STAGING_DIR_HOST：‎‎构建组件运行的系统系统系统（即）的系统根路径。‎recipe-sysroot

• ‎ ‎‎STAGING_DIR_NATIVE：‎‎为构建主机构建组件时使用的机根路径（即）。‎recipe-sysroot-native

• ‎ ‎‎STAGING_DIR_TARGET：‎‎当构建用于在系统上执行的组件并生成另一台机器（例如跨加拿大配方）的代码时，系统根的路径。‎

‎文件‎‎变量定义了在‎‎包‎‎中进入每个包的文件。如果你想要如何做到这一点的细节，你可以看看‎‎包。‎

‎根据正在创建的包类型（RPM、DEB 或‎‎IPK），do_package_write_*‎‎任务创建实际包并将其放置在包源区域（即 。您可以查看"‎‎包馈送‎‎"部分，了解构建过程该部分的更多详细信息。‎${TMPDIR}/deploy

4.3.5.5图像生成

一旦包被拆分并存储在包源区域，构建系统使用 BitBake 生成根文件系统图像：

图像生成过程由多个阶段组成，取决于多个任务和变量。 do_rootfs任务为图像创建根文件系统（文件和目录结构）。此任务使用几个关键变量来帮助创建要实际安装的包列表：

• IMAGE_INSTALL：列出从包装源区域安装的基本包集。

• PACKAGE_EXCLUDE：指定不应安装到图像中的包。

• IMAGE_FEATURES： 指定图像中要包含的功能。其中大多数功能映射到用于安装的其他包。

• PACKAGE_CLASSES：指定用于使用的包后端（例如.RPM、DEB 或 IPK），从而帮助确定在包馈送区域内查找包裹的位置。

• IMAGE_LINGUAS：确定安装额外语言支持包的语言。

• PACKAGE_INSTALL：将最终的包裹列表传递给包装经理，以便安装到图像中。

随着IMAGE_ROOTFS指向正在构建的文件系统的位置和提供要安装的软件包最终列表的PACKAGE_INSTALL变量，创建了根文件系统。

包裹安装由包经理控制（例如 dnf/rpm、opkg 或 apt/dpkg），无论是否启用了目标的包管理。在过程结束时，如果目标无法启用包管理，则从根文件系统中删除包管理器的数据文件。作为封装安装最后阶段的一部分，将运行作为封装一部分的安装脚本。当目标系统首次启动时，任何未能在构建主机上运行的脚本都运行在目标上。如果您使用仅读的根文件系统，则所有后安装脚本必须在封装安装阶段的构建主机上成功，因为目标上的根文件系统仅限读取。

任务的最后阶段处理后处理。后处理包括创建一个显性文件和优化。do_rootfs

清单文件（）与根文件系统图像位于同一目录中。此文件逐行列出已安装的包。例如，清单文件可用于测试类，以确定是否运行特定测试。有关其他信息，请参阅IMAGE_MANIFEST变量。.manifest

在整个图像中运行的优化过程包括，以及ROOTFS_POSTPROCESS_COMMAND变量定义的任何其他后处理命令。该过程优化了库的大小，而流程优化了共享库的动态链接，以减少可执行库的启动时间。mklibsprelinkmklibsprelink

根文件系统构建后，通过do_image任务开始对图像进行处理。构建系统运行由IMAGE_PREPROCESS_COMMAND变量定义的任何预处理命令。此变量指定在构建系统创建最终图像输出文件之前要调用的功能列表。

构建系统根据IMAGE_FSTYPES变量中指定的图像类型，根据需要动态创建任务。该过程将所有内容转换为图像文件或一组图像文件，并可以压缩根文件系统图像，以减少图像的整体大小。用于根文件系统的格式取决于IMAGE_FSTYPES变量。压缩取决于格式是否支持压缩。do_image_*

例如，创建特定图像类型时动态创建的任务将采取以下形式：

do_image_type

因此，如果IMAGE_FSTYPES指定的类型是动态生成的任务如下：ext4

do_image_ext4

图像创建中涉及的最后任务是do_image_complete任务。此任务通过应用通过IMAGE_POSTPROCESS_COMMAND变量定义的任何图像后处理来完成图像。该变量指定了构建系统创建最终图像输出文件后要调用的功能列表。

4.3.5.6SDK 一代

开放式构建系统使用 BitBake 生成标准 SDK 和可扩展 SDK （eSDK） 的软件开发套件 （SDK） 安装脚本：

注意

有关交叉开发工具链生成的更多信息，请参阅“交叉开发工具链生成”部分。有关使用 do_populate_sdk 任务构建交叉开发工具链时获得的优势的信息，请参阅Yocto 项目应用程序开发和可扩展软件开发工具包 (eSDK) 手册中的“构建 SDK 安装程序”部分。

与图像生成一样，SDK 脚本过程由几个阶段组成，并依赖于许多变量。该 do_populate_sdk 和 do_populate_sdk_ext 任务，用它来帮助这些关键变量创建包的实际安装列表。有关图中列出的变量的信息，请参阅“应用程序开发 SDK ”部分。

该do_populate_sdk任务有助于创建标准 SDK 并处理两个部分：目标部分和主机部分。目标部分是为目标硬件构建的部分，包括库和头文件。主机部分是在SDKMACHINE上运行的 SDK 部分 。

该do_populate_sdk_ext任务有助于创建可扩展的 SDK，并以不同于其对应部分对标准 SDK 的方式处理主机和目标部分。对于可扩展 SDK，该任务封装了构建系统，其中包括 SDK 所需的一切（主机和目标）。

无论构建的 SDK 类型如何，任务都会执行一些清理工作，然后创建一个交叉开发环境设置脚本和任何所需的配置文件。最终输出是交叉开发工具链安装脚本（.sh文件），其中包括环境设置脚本。

4.3.5.7标记文件和任务的重新运行

对于每个成功完成的任务，BitBake 会在STAMPS_DIR 目录中写入一个戳文件。戳文件的文件名的开头由STAMP变量决定，文件名的结尾由任务名称和当前输入校验和组成。

为了确定是否需要重新运行任务，BitBake 检查是否存在具有匹配输入校验和的标记文件。在这种情况下，假定任务的输出存在并且仍然有效。否则，任务将重新运行。

由于STAMPS_DIR通常是TMPDIR的子目录，删除 TMPDIR也将删除STAMPS_DIR，这意味着将正确地重新运行任务以重新填充TMPDIR。

如果您希望某些任务始终被视为“过时”，您可以使用nostamp varflag对其进行标记。如果其他任务依赖于这样的任务，那么该任务也将始终被视为过时，这可能不是您想要的。

有关如何查看任务签名信息的详细信息，请参阅Yocto 项目开发任务手册中的“查看任务变量依赖关系”部分。

4.3.5.8场景任务和共享状态

到目前为止的任务描述假设 BitBake 需要构建一切，并且不存在可用的预构建对象。如果预建对象可用，BitBake 确实支持跳过任务。这些对象通常以共享状态 (sstate) 缓存的形式提供。

setscene 任务（即do_taskname _setscene）的想法是任务的一个版本，BitBake 可以跳到最终结果，并根据需要简单地将一组文件放置到特定位置，而不是构建某些东西。在某些情况下，有一个 setscene 任务变体是有意义的（例如在do_package_write_* 任务中生成包文件 ）。在其他情况下，它没有意义（例如 do_patch任务或 do_unpack任务），因为所涉及的工作将等于或大于底层任务。

在构建系统中，具有 setscene 变体的常见任务是 do_package、 do_package_write_*、 do_deploy、 do_packagedata和 do_populate_sysroot。请注意，这些任务代表了其输出是最终结果的大多数任务。

构建系统了解这些任务与其他先前任务之间的关系。例如，如果运行BitBake的 do_populate_sysroot_setscene东西，它没有任何意义运行任何的do_fetch，do_unpack，do_patch， do_configure，do_compile，和do_install任务。但是，如果 do_package需要运行，BitBake 需要运行那些其他任务。

如果一切都可以来自 sstate 缓存，那会变得更加复杂，因为根本不需要某些对象。例如，如果没有要编译或修补的内容，则不需要编译器或本机工具（例如 quilt）。如果do_package_write_*包可以从 sstate 获得，BitBake 不需要do_package任务数据。

为了处理所有这些复杂性，BitBake 分两个阶段运行。首先是“场景”阶段。在此阶段，BitBake 首先检查 sstate 缓存中是否有它计划构建的任何目标。BitBake 会快速检查对象是否存在，而不是进行完整下载。如果什么都不存在，则第二阶段（即场景阶段）完成并继续进行主要构建。

如果在 sstate 缓存中找到对象，构建系统将从用户指定的最终目标向后工作。例如，如果正在构建映像，则构建系统首先查找该映像所需的包以及构建映像所需的工具。如果这些可用，则不需要编译器。因此，甚至没有下载编译器。如果发现某些内容不可用，或者下载或 setscene 任务失败，则构建系统会尝试从缓存中安装依赖项，例如编译器。

sstate 缓存中对象的可用性由BB_HASHCHECK_FUNCTION 变量指定的函数处理，并返回可用对象列表。BB_SETSCENE_DEPVALID 变量指定的函数是确定是否需要遵循给定依赖关系以及是否需要传递任何给定关系的函数。该函数返回 True 或 False 值。

4.3.6图像

构建系统生成的映像是根文件系统的压缩形式，可以在目标设备上启动。您可以从一般工作流程图中看到，BitBake 输出部分由图像组成。本节将仔细查看此输出：

此输出的特定形式是一组文件，其中包括自解压 SDK 安装程序 ( *.sh)、主机和目标清单文件以及用于 SDK 测试的文件。当 SDK 安装程序文件运行时，它会安装 SDK。SDK 由一个交叉开发工具链、一组库和头文件以及一个 SDK 环境设置脚本组成。运行此安装程序实质上是设置您的交叉开发环境。您可以将跨工具链视为“主机”部分，因为它运行在 SDK 机器上。您可以将库和头文件视为“目标”部分，因为它们是为目标硬件构建的。添加了环境设置脚本，以便您可以在使用工具之前初始化环境。

SDK 的所有输出文件都写入Build Directorydeploy/sdk内的文件夹中，如上图所示。根据 SDK 的类型，有几个变量可以配置这些文件。以下是与可扩展 SDK 关联的变量：

• DEPLOY_DIR：指向deploy目录。

• SDK_EXT_TYPE：控制是否将共享状态工件复制到可扩展 SDK 中。默认情况下，所有必需的共享状态工件都被复制到 SDK 中。

• SDK_INCLUDE_PKGDATA：指定 packagedata 是否包含在“world”目标中所有配方的可扩展 SDK 中。

• SDK_INCLUDE_TOOLCHAIN：指定在构建可扩展 SDK 时是否包含工具链。

• SDK_LOCAL_CONF_WHITELIST：允许从构建系统配置到可扩展 SDK 配置的变量列表。

• SDK_LOCAL_CONF_BLACKLIST：不允许从构建系统配置进入可扩展 SDK 配置的变量列表。

• SDK_INHERIT_BLACKLIST：要从可扩展 SDK 配置中全局删除的INHERIT值中删除的类列表 。

下一个列表显示了与标准 SDK 关联的变量：

• DEPLOY_DIR：指向deploy目录。

• SDKMACHINE：指定运行交叉开发工具以创建目标硬件包的机器的体系结构。

• SDKIMAGE_FEATURES：列出要包含在 SDK 的“目标”部分中的功能。

• TOOLCHAIN_HOST_TASK：列出构成 SDK 主机部分（即在SDKMACHINE上运行的部分）的包。当您使用 创建的SDK，一组默认套餐适用。此变量允许您添加更多包。bitbake -c populate_sdk imagename

• TOOLCHAIN_TARGET_TASK：列出构成 SDK 目标部分的包（即为目标硬件构建的部分）。

• SDKPATH：定义安装脚本提供的默认 SDK 安装路径。

• SDK_HOST_MANIFEST：列出构成 SDK 主机部分的所有已安装包。此变量在可扩展 SDK 开发中也起着次要作用。但是，它主要用于标准 SDK。

• SDK_TARGET_MANIFEST：列出构成 SDK 目标部分的所有已安装包。此变量对于可扩展 SDK 开发也起着次要作用。但是，它主要用于标准 SDK。

4.4交叉开发工具链生成

在创建交叉开发工具链时，Yocto 项目会为您完成大部分工作。本节提供有关如何创建和使用交叉开发工具链的一些技术背景。有关工具链的更多信息，您还可以参阅Yocto 项目应用程序开发和可扩展软件开发工具包 (eSDK)手册。

在 Yocto Project 开发环境中，交叉开发工具链用于构建在目标硬件上运行的图像和应用程序。只需几个命令，OpenEmbedded 构建系统就会为您创建这些必要的工具链。

下图显示了有关工具链构建和使用的高级构建环境。

注意

不使用可扩展 SDK，gcc-cross-canadian 因为此 SDK 提供了 OpenEmbedded 构建系统的副本，并且其中的 sysroot 包含gcc-cross.

注意

如果 Yocto 项目支持您的目标架构，您可以利用 Yocto 项目附带的预构建映像，并且已经包含交叉开发工具链安装程序。

注意

有关构建交叉开发工具链安装程序时获得的优势的信息，请参阅Yocto 项目应用程序开发和可扩展软件开发工具包 (eSDK) 手册中的“构建 SDK 安装程序”附录。

4.5共享状态缓存

按照设计，OpenEmbedded 构建系统从头开始构建所有内容，除非BitBake可以确定不需要重新构建部分。从根本上说，从头开始构建很有吸引力，因为这意味着所有部件都是全新构建的，并且不可能出现可能导致问题的陈旧数据。当开发人员遇到问题时，他们通常会默认从头开始构建，因此他们从一开始就知道状态。

从头开始构建图像对这个过程来说既是优点也是缺点。如上一段所述，从头开始构建可确保一切都是最新的并从已知状态开始。然而，从头开始构建也需要更长的时间，因为它通常意味着重建不一定需要重建的东西。

Yocto 项目实现了支持增量构建的共享状态代码。共享状态代码的实现回答了以下问题，这些问题是 OpenEmbedded 增量构建支持系统中的基本障碍：

• 系统的哪些部分发生了变化，哪些部分没有发生变化？

• 如何删除和替换更改的软件？

• 不需要重新构建的预构建组件在可用时如何使用？

对于第一个问题，构建系统通过创建任务输入的校验和（或签名）来检测给定任务“输入”的变化。如果校验和发生变化，系统会假设输入发生了变化，需要重新运行任务。对于第二个问题，共享状态 (sstate) 代码跟踪哪些任务将哪些输出添加到构建过程。这意味着可以删除、升级或以其他方式操纵给定任务的输出。第三个问题部分由第二个问题的解决方案解决，假设构建系统可以从远程位置获取 sstate 对象并在它们被认为有效时安装它们。

本节的其余部分详细介绍了整体增量构建架构、校验和（签名）和共享状态。

PACKAGE_ARCHS[vardepsexclude] = "MACHINE"

PACKAGE_ARCHS[vardeps] = "MACHINE"

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"

BB_SIGNATURE_HANDLER ?= "OEBasicHash"

DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
SSTATETASKS += "do_deploy"
do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"python do_deploy_setscene () {sstate_setscene(d)
}
addtask do_deploy_setscene
do_deploy[dirs] = "${DEPLOYDIR} ${B}"
do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"

SSTATE_MIRRORS ?= "\file://.\* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \file://.\* file:///some/local/dir/sstate/PATH"

4.6自动添加运行时依赖

OpenEmbedded 构建系统会自动在包之间添加常见类型的运行时依赖项，这意味着您无需使用RDEPENDS显式声明包 。有三种自动机制（shlibdeps、pcdeps和depchains）分别处理共享库、包配置 (pkg-config) 模块 -dev和-dbg包。对于其他类型的运行时依赖项，您必须手动声明依赖项。

• shlibdeps：在每个recipe的 do_package任务中，都会定位到recipe安装的所有共享库。对于每个共享库，包含共享库的包被注册为提供共享库。更具体地说，该包被注册为提供 库的 soname。生成的共享库到包映射由 do_packagedata 任务全局保存在 PKGDATA_DIR 中。

  同时，检查配方安装的所有可执行文件和共享库，以查看它们链接到哪些共享库。对于找到的每个共享库依赖项，查询PKGDATA_DIR以查看某个包（可能来自不同的配方）是否包含共享库。如果找到这样的包，则将运行时依赖项从依赖于共享库的包添加到包含该库的包。

  自动添加的运行时依赖项还包括版本限制。此版本限制指定至少必须使用提供共享库的包的当前版本，就好像“包（> = 版本）”已添加到RDEPENDS 一样。如果需要，这会在安装依赖于共享库的包时强制升级包含共享库的包。

  如果您想避免将包注册为提供特定共享库（例如，因为该库仅供内部使用），则将该库添加到 包配方中的PRIVATE_LIBS 中。

• pcdeps：在do_package每个recipe的任务期间，recipe*.pc安装的所有pkg-config模块（文件）都被定位。对于每个模块，包含该模块的包被注册为提供该模块。生成的模块到包的映射由 任务全局保存在PKGDATA_DIR 中do_packagedata。

  同时，对配方安装的所有 pkg​​-config 模块进行检查，以查看它们所依赖的其他 pkg-config 模块。如果一个模块包含指定另一个模块的“Requires:”行，则该模块被视为依赖于另一个模块。对于每个模块依赖项，查询PKGDATA_DIR以查看某个包是否包含该模块。如果找到这样的包，则将运行时依赖项从依赖于该模块的包添加到包含该模块的包。

  注意

  pcdeps 机制最常推断 -dev 包之间的依赖关系。

• depchains: 如果一个包foo依赖于一个包bar，那么foo-dev和foo-dbg也分别依赖于 bar-dev和bar-dbg。以-dev 包为例，bar-dev包可能提供 所需的头文件和共享库符号链接foo-dev，这表明包之间需要依赖关系。

  添加的依赖项采用RRECOMMENDSdepchains的形式 。

  注意

  默认情况下，对foo-dev也有RDEPENDS样式的依赖 foo，因为RDEPENDS:${PN}-dev（在 bitbake.conf 中设置）的默认值包括“${PN}”。

  确保依赖链永远不会中断，-dev并且 -dbg默认情况下始终生成包，即使包是空的。有关更多信息，请参阅 ALLOW_EMPTY变量。

的do_package任务依赖于do_packagedata在每个配方的任务DEPENDS通过使用的[deptask] 声明，这保证了所需的，只要当所要求的共享库/模块到包映射信息将是可用的DEPENDS已正确设置。

4.7 Fakeroot 和 Pseudo

当允许执行通常为 root 用户保留的某些操作（例如do_install、 do_package_write*、 do_rootfs和 do_image*）时，某些任务更容易实现 。例如，该do_install任务受益于能够将已安装文件的 UID 和 GID 设置为任意值。

允许任务仅执行 root 操作的一种方法是要求BitBake以 root 身份运行。但是这种方法比较麻烦，而且存在安全问题。实际使用的方法是在“假”root 环境中运行受益于root 权限的任务。在此环境中，任务及其子进程认为它们以 root 用户身份运行，并看到文件系统的内部一致视图。只要生成最终输出（例如包或图像）不需要 root 权限，一些早期步骤在假 root 环境中运行的事实不会导致问题。

在伪根环境中运行任务的能力被称为“ fakeroot ”，它源自 BitBake 关键字/变量标志，为任务请求伪根环境。

在OpenEmbedded Build System 中，实现 fakeroot 的程序称为Pseudo。使用环境变量伪覆盖系统调用LD_PRELOAD，导致以root身份运行的错觉。为了跟踪需要 root 权限的操作产生的“假”文件所有权和权限，Pseudo 使用了 SQLite 3 数据库。该数据库存储在 ${WORKDIR 中，}/pseudo/files.db 用于单个配方。将数据库存储在文件中而不是内存中可以在任务和构建之间提供持久性，这是使用 fakeroot 无法实现的。

fakeroot do_mytask () {...
}
do_mytask[depends] += "virtual/fakeroot-native:do_populate_sysroot"

有关更多信息，请参阅BitBake 用户手册中的 FAKEROOT*变量。您还可以参考“为什么不是 Fakeroot？”有关 Fakeroot 和 Pseudo 背景信息的文章。