3 理解和创建层

OpenEmbedded 构建系统支持将 Metadata 组织到多个层中，以隔离不同 类型的定制。层模型的入门信息见概述与概念手册的 “Yocto Project 层模型”。

调用下文的 bitbake-layers 前，务必先用项目环境设置脚本 初始化构建环境。 否则 Shell 无法找到命令或构建配置。

3 创建自己的层

创建层的一般步骤如下：

  1. 检查已有层： 创建之前，先确认是否已有层包含所需元数据。 OpenEmbedded 元数据索引 列出社区中可用于 Yocto Project 的层，可能有完全符合或接近需求的层。

    备注

    BSP 层介绍见板级支持包开发指南的 “BSP 层”。

  2. 创建新层： 创建层目录。bitbake-layers create-layer 可简化通用层 创建，将其放在 Source Directory 中其他层旁边。

    最简单的用法是在当前目录创建 "your_layer_name"：

    $ bitbake-layers create-layer your_layer_name

    虽非强制要求，仍建议目录名以 "meta-" 开头，例如:

    meta-mylayer
meta-GUI_xyz
meta-mymachine

    除少数例外，层名遵循:

    meta-root_name

    这样可避免工具、组件或变量假定层名带 "meta-" 时出现问题。例如，后续 配置文件中的多个变量会追加去掉 "meta-" 的层名称。

    以下命令在当前目录创建 meta-scottrif：

    $ bitbake-layers create-layer meta-scottrif
NOTE: Starting bitbake server...
Add your new layer with 'bitbake-layers add-layer meta-scottrif'

    如命令提示所述，要让 OpenEmbedded Build System 使用该层，需将其 加入 build/conf/bblayers.conf。详见 “使用 bitbake-layers 脚本添加层”。

    默认创建的内容包括：

    • 带默认定义的 conf/layer.conf 配置文件。

      典型配置项如下：

      • BBPATH：将层根目录加入 BitBake 搜索路径，用于定位类文件 （.bbclass）、配置文件及 include、require 引入的文件。 与可执行程序的 PATH 类似，BitBake 使用第一个同名匹配文件， 因此建议自定义层中的类和配置文件名称保持唯一。

        文件包含机制详见 BitBake 用户手册的 Locating Include Files。

      • BBFILES：定义层中所有配方的位置。

      • BBFILE_COLLECTIONS：为层定义唯一标识符，供 OpenEmbedded Build System 引用。例如，"yoctobsp" 代表 "meta-yocto-bsp" 层。

        其他层通过 LAYERDEPENDS 指定依赖时使用此名称。

      • BBFILE_PATTERN：解析时立即展开，提供层目录。

      • BBFILE_PRIORITY：当不同层存在同名配方时，确定选择优先级。

      • LAYERVERSION：定义层版本号，其他层可在 LAYERDEPENDS 中指定对这一确切版本的依赖。

      • LAYERDEPENDS：列出依赖层，使用 BBFILE_COLLECTIONS 定义的名称。

      • LAYERSERIES_COMPAT：列出兼容的 Yocto Project 发行版 小写代号， 例如 "blacksail"。

        此变量有助于判断某层是否跟进了当前版本。

    • recipes-example 子目录，其中的 example 子目录包含 example.bb 示例配方。

    • COPYING.MIT 许可证声明。脚本假定层自身内容采用多数层常用的 MIT 许可证。

    • 描述新层内容的 README。

    如果优先级不采用默认 "6"，可使用 --priority，或创建后编辑 conf/layer.conf 的 BBFILE_PRIORITY。示例配方名称和版本可 通过 --example-recipe-name 和 --example-recipe-version 修改。

    理解命令最简单的方法是实际试用，也可运行 bitbake-layers create-layer --help 查看用法。

  3. 添加内容： 根据层类型添加文件。机器支持配置放在 conf/machine/， 发行版策略放在 conf/distro/，新配方放在 recipes-* 子目录。

    备注

    符合 Yocto Project 要求的层目录结构见 BSP 开发指南的 “文件系统布局示例”。

  4. 按需测试兼容性： 如需为层及使用它的应用申请 Yocto Project 兼容标志， 请按兼容性申请流程操作，详见 “确保层与 Yocto Project 兼容”。

3 创建层的推荐实践

为便于维护，并避免影响其他机器的构建，请考虑：

  • 避免覆盖其他层的完整配方： 不要复制整份配方后修改。应使用追加文件 （.bbappend），仅覆盖需要修改的部分。

  • 避免复制包含文件： 为使用该文件的各配方添加 .bbappend。若新配方 需要包含文件，使用相对于原层目录的路径，例如 require recipes-core/package/file.inc， 而非 require file.inc。如果不得不覆盖包含文件，可能说明其 设计存在不足。应尝试解决根因，例如请维护者增加变量，使需要覆盖的内容 容易调整。

  • 合理组织层： 正确使用追加文件中的覆盖，并妥善放置机器专用文件，可以 避免错误元数据影响其他机器。例如：

    • 修改变量以支持不同机器： 假设 meta-one 层支持机器 "one"， 在 base-files.bbappend 中修改 DEPENDS，增加 "foo" 依赖:

      DEPENDS = "foo"

      任何包含 meta-one 的构建都会增加该依赖，但可能并非所有机器都 需要。例如，为 "two" 构建时，只要 build/conf/bblayers.conf 包含 meta-one，它的 base-files 也会依赖 foo。

      要仅对 "one" 生效，应添加机器覆盖:

      DEPENDS:one = "foo"

      :append 和 :prepend 也应采用同样策略:

      DEPENDS:append:one = " foo"
DEPENDS:prepend:one = "foo "

      以下 linux-yocto.inc 片段是实际示例，仅为部分受支持架构调整内核 编译和链接选项:

      DEPENDS:append:aarch64 = " libgcc"
KERNEL_CC:append:aarch64 = " ${TOOLCHAIN_OPTIONS}"
KERNEL_LD:append:aarch64 = " ${TOOLCHAIN_OPTIONS}"

DEPENDS:append:nios2 = " libgcc"
KERNEL_CC:append:nios2 = " ${TOOLCHAIN_OPTIONS}"
KERNEL_LD:append:nios2 = " ${TOOLCHAIN_OPTIONS}"

DEPENDS:append:arc = " libgcc"
KERNEL_CC:append:arc = " ${TOOLCHAIN_OPTIONS}"
KERNEL_LD:append:arc = " ${TOOLCHAIN_OPTIONS}"

KERNEL_FEATURES:append:qemuall = " features/debug/printk.scc"

    • 将机器专用文件放到专用位置： 如果 base-files.bb 等基础配方通过 SRC_URI 引用文件，可以用追加文件提供自己的版本。例如， meta-one/recipes-core/base-files/base-files.bbappend 可通过 FILESEXTRAPATHS 扩展 FILESPATH:

      FILESEXTRAPATHS:prepend := "${THISDIR}/${BPN}:"

      将文件放在 meta-one/recipes-core/base-files/base-files/ 后， "one" 构建就能找到它。但若其他机器的构建也包含 meta-one，且 该位置是 FILESPATH 首个匹配位置，其他机器也会使用它。

      应改放到机器专用子目录，例如 meta-one/recipes-core/base-files/base-files/one/。这样既能保证 仅用于 "one"，也使构建过程更快定位文件。

      因此，若要将 SRC_URI 引用的文件限制于特定机器构建，就应将 它们放入层内的机器专用子目录。

  • 申请 Yocto Project 兼容性： 如需为层或使用它的应用使用兼容标志， 参阅 “确保层与 Yocto Project 兼容”。

  • 遵循层命名惯例： 将自定义层存放在 meta-layer_name 格式的 Git 仓库。

  • 在本地集中放置层： 将仓库克隆到 Source Directory，与其他层并列。

3 确保层与 Yocto Project 兼容

确保自建层能与现有 Yocto Project 层良好协作，可使社区成员更容易使用，也 可能获得使用 Yocto Project Compatible 标志的许可。

备注

只有 Yocto Project 成员组织可以使用此标志，不向一般用户开放。加入方式 见 Yocto Project 网站。

兼容性计划通过层申请流程，授权层及应用使用标志。流程包括：

  1. 通过 yocto-check-layer 脚本测试。其约束来自层的实际使用经验及已知 问题。必须获得 "PASS" 才能完成兼容性登记。

  2. 填写 https://www.yoctoproject.org/compatible-registration/ 上的申请表。

获得许可需满足：

  • 能够勾选脚本检查已获得 "PASS"。

  • 对表单问题回答 "Yes"，或为 "No" 提供可接受解释。

  • 属于 Yocto Project 成员组织。

下文介绍申请表和检查脚本。

3 申请 Yocto Project 兼容性计划

用表单申请层认证，成功后即可为层及使用它的应用使用兼容标志。

表单位于 https://www.yoctoproject.org/compatible-registration，按表单说明完成申请。

内容包括：

  • 联系信息： 填写所需联系信息，并列出层兼容的 Yocto Project 已发布版本。

  • 接受标准： 为清单各项回答 "Yes" 或 "No"，在表单底部解释否定回答。

  • 建议事项： 回答关于 Linux 内核使用和构建成功情况的问题。

3 yocto-check-layer 脚本

该脚本评估层与 Yocto Project 的兼容性。提交申请前应先运行，必须得到 "PASS" 才能成功处理申请。

测试分 COMMON、BSP 和 DISTRO 三类。发行版层需要通过 COMMON 与 DISTRO， BSP 层需要通过 COMMON 与 BSP。

在构建目录执行:

$ source oe-init-build-env
$ yocto-check-layer your_layer_directory

将命令中的层目录替换为实际路径。

通过 --dependency 传入层依赖:

$ source oe-init-build-env
$ yocto-check-layer --dependency <layer1_directory> <layer2_directory> ... -- your_layer_directory

BSP 层还应传入 --machines:

$ source oe-init-build-env
$ yocto-check-layer --machines <machine1> <machine2> ... -- your_layer_directory

这些机器对应 BSP 层 conf/machine/ 中的配置。

脚本判断层类型，然后运行相应测试。主要测试如下：

  • common.test_readme：检查层存在非空 README。

  • common.test_security：检查层内或所在 Git 仓库顶层存在 SECURITY.md 或类似文件。

  • common.test_parse：检查 BitBake 能无错误解析，即 bitbake -p。

  • common.test_show_environment：检查全局和配方环境无错误，即 bitbake -e。

  • common.test_world：检查 bitbake world 可用。

  • common.test_world_inherit_class：继承 yocto-check-layer 后检查 bitbake world 可用。

  • common.test_patches_upstream_status：检查所有补丁包含 补丁上游状态。

  • common.test_signatures：确保 BSP 和 DISTRO 层不附带改变签名的配方。

  • common.test_layerseries_compat：检查层兼容性设置正确。

  • bsp.test_bsp_defines_machines：检查 BSP 层提供机器配置。

  • bsp.test_bsp_no_set_machine：确保添加 BSP 层时不自动设置机器。

  • bsp.test_machine_world：确保选择任意机器时 bitbake world 都可用。

  • bsp.test_machine_signatures：确保某台机器的构建只影响其专用任务的签名。

  • distro.test_distro_defines_distros：检查 DISTRO 层提供发行版配置。

  • distro.test_distro_no_set_distros：确保添加 DISTRO 层时不自动设置发行版。

完整列表见 OpenEmbedded-Core (OE-Core) 的 scripts/lib/checklayer/cases。

3 启用层

构建系统使用新层前，需在 Build Directory 的 build/conf/bblayers.conf 中，将层路径加入 BBLAYERS。 下面启用 meta-mylayer，注意它位于之前检出的官方 poky 仓库之外:

# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS ?= " \
    /home/user/poky/meta \
    /home/user/poky/meta-poky \
    /home/user/poky/meta-yocto-bsp \
    /home/user/mystuff/meta-mylayer \
    "

BitBake 按 BBLAYERS 从上到下解析各 conf/layer.conf，处理过程中 将该层的配方、类和配置加入源码目录。

3 通过自己的层追加其他层元数据

向另一配方追加元数据的文件称为 BitBake 追加文件，后缀为 .bbappend， 被追加的配方后缀为 .bb。

通过自己层中的 .bbappend，可以增加或修改另一层的配方内容，无需复制 原配方。追加文件位于自己的层，主 .bb 文件位于其他层。

这种方式不仅避免重复，还能自动沿用另一层对原配方的更新。如果复制配方， 则必须手动合并这些变化。

追加文件必须与对应配方具有相同基础名称。例如，someapp_3.1.bbappend 只适用于 someapp_3.1.bb。因此两者与版本号绑定；原配方升级并改名时， 追加文件也需改名，并可能需要更新。

BitBake 启动时发现没有匹配配方的 .bbappend 会报错。最佳做法是改名以 匹配新版本，同时检查追加内容是否仍适用。

也可以在追加文件名使用 %。例如，someapp_6.%.bbappend 适用于所有 6.* 次要版本，只有主版本更新时才会出错。

另外还可使用 BBMASK，尤其适合无法修改追加文件的情况。

3 通过层覆盖文件

以 formfactor 主配方及追加文件为例。主配方 formfactor_0.0.bb 位于 OpenEmbedded-Core (OE-Core) 的 meta/recipes-bsp/formfactor:

SUMMARY = "Device formfactor information"
DESCRIPTION = "A formfactor configuration file provides information about the \
target hardware for which the image is being built and information that the \
build system cannot obtain from other sources such as the kernel."
SECTION = "base"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"

SRC_URI = "file://config file://machconfig"
S = "${UNPACKDIR}"

PACKAGE_ARCH = "${MACHINE_ARCH}"
INHIBIT_DEFAULT_DEPS = "1"

do_install() {
        # Install file only if it has contents
        install -d ${D}${sysconfdir}/formfactor/
        install -m 0644 ${S}/config ${D}${sysconfdir}/formfactor/
        if [ -s "${S}/machconfig" ]; then
                install -m 0644 ${S}/machconfig ${D}${sysconfdir}/formfactor/
        fi
}

注意主配方的 SRC_URI，它告诉构建系统到哪里查找文件。

以下 formfactor_0.0.bbappend 来自 Raspberry Pi BSP 层 meta-raspberrypi， 位于 recipes-bsp/formfactor:

FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"

构建系统默认通过 FILESPATH 查找文件。追加文件设置 FILESEXTRAPATHS 扩展搜索位置，这是添加文件搜索目录最可靠、推荐的方法。

示例加入 ${THISDIR}/${PN}，展开为追加 文件同目录下的 formfactor 子目录，即 meta-raspberrypi/recipes-bsp/formfactor 下的子目录。需要建立对应结构， 保存层将要提供的文件或补丁。

由于引用 THISDIR，必须使用立即展开的 :=。末尾冒号同样重要， 确保列表条目仍由冒号分隔。

备注

THISDIR 由 BitBake 自动定义，切勿自行设置。使用 FILESEXTRAPATHS 的 ":prepend"，可确保自己的路径优先搜索。

并非所有追加文件都增加文件。许多仅增加 systemd 等构建选项， 这类追加文件无需使用 FILESEXTRAPATHS。

最终，在 FILESOVERRIDES 包含 rpi 的 Raspberry Pi 上， do_fetch 会使用 meta-raspberrypi/recipes-bsp/formfactor/formfactor/rpi/machconfig； do_install 中非零文件大小检查通过，文件便会安装。

3 通过层安装额外文件

再看 xserver-xf86-config。主配方 xserver-xf86-config_0.1.bb 位于 OpenEmbedded-Core (OE-Core) 的 meta/recipes-graphics/xorg-xserver:

SUMMARY = "X.Org X server configuration file"
HOMEPAGE = "http://www.x.org"
SECTION = "x11/base"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"

SRC_URI = "file://xorg.conf"

S = "${UNPACKDIR}"

CONFFILES:${PN} = "${sysconfdir}/X11/xorg.conf"

PACKAGE_ARCH = "${MACHINE_ARCH}"
ALLOW_EMPTY:${PN} = "1"

do_install () {
     if test -s ${UNPACKDIR}/xorg.conf; then
             install -d ${D}/${sysconfdir}/X11
             install -m 0644 ${UNPACKDIR}/xorg.conf ${D}/${sysconfdir}/X11/
     fi
}

以下 xserver-xf86-config_%.bbappend 来自 meta-raspberrypi 的 recipes-graphics/xorg-xserver:

FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"

SRC_URI:append:rpi = " \
    file://xorg.conf.d/98-pitft.conf \
    file://xorg.conf.d/99-calibration.conf \
"
do_install:append:rpi () {
    PITFT = "${@bb.utils.contains("MACHINE_FEATURES", "pitft", "1", "0", d)}"
    if [ "${PITFT}" = "1" ]; then
        install -d ${D}/${sysconfdir}/X11/xorg.conf.d/
        install -m 0644 ${UNPACKDIR}/xorg.conf.d/98-pitft.conf ${D}/${sysconfdir}/X11/xorg.conf.d/
        install -m 0644 ${UNPACKDIR}/xorg.conf.d/99-calibration.conf ${D}/${sysconfdir}/X11/xorg.conf.d/
    fi
}

FILES:${PN}:append:rpi = " ${sysconfdir}/X11/xorg.conf.d/*"

与上例一样，它设置 FILESEXTRAPATHS。另外，当 FILESOVERRIDES 包含 rpi 时，利用 SRC_URI 添加额外源文件。 do_install 再检查相应 MACHINE_FEATURES，启用时安装 这些文件。文件也列入 FILES，确保会打包。

3 设置层优先级

每个层都有优先级。不同层存在同名配方时，数字较大的层优先。优先级也影响同一 配方多个 .bbappend 的应用顺序。可以手动设置，或让构建系统按层依赖计算。

手动设置时，使用 BBFILE_PRIORITY 并追加层的基础名称:

BBFILE_PRIORITY_mylayer = "1"

备注

高优先级层中 PV 较低的配方，也可能优先于其他层的高版本配方。

层优先级目前不影响 .conf 或 .bbclass 的优先顺序，未来 BitBake 版本可能改变这一点。

3 通过层提供全局配置

有时需要在层加入构建后，使某些配置对整个环境生效。layer.conf 是影响 全局的 configuration file，可以用于此目的。

警告

不应在 layer.conf 中无条件提供全局配置。下文 通过层有条件地提供全局配置 介绍仅在满足特定条件时提供配置的方法。

例如，层提供 linux-custom 内核配方，希望让 PREFERRED_PROVIDER_virtual/kernel 指向它:

PREFERRED_PROVIDER_virtual/kernel = "linux-custom"

可以将其定义在 layer.conf。如果层位于 BBLAYERS 末尾，此设置 优先于前面的赋值，但后续解析的机器或发行版等 configuration file 仍可覆盖它。

3 通过层有条件地提供全局配置

有时只有启用层提供的某项功能后，才应应用全局配置。layer.conf 解析较早， 此时 DISTRO_FEATURES 和 MACHINE_FEATURES 尚不可用，无法 直接基于它们条件赋值。可以结合 USER_CLASSES 和条件 require 绕过此限制。

假设 meta-mylayer 提供名为 mylayer-kernel 的 发行版功能，仅当 DISTRO_FEATURES 包含 该功能时，才设置内核 PREFERRED_PROVIDER：

  1. 在 meta-mylayer/conf/distro/include/ 创建包含文件，例如 mylayer-kernel-provider.inc，将内核提供者设为 linux-custom:

    PREFERRED_PROVIDER_virtual/kernel = "linux-custom"

  2. 在 layer.conf 提供包含文件路径:

    META_MYLAYER_KERNEL_PROVIDER_PATH = "${LAYERDIR}/conf/distro/include/mylayer-kernel-provider.inc"

  3. 在 meta-mylayer/classes-global/ 创建 meta-mylayer-cfg.bbclass， 使用 layer.conf 中的 META_MYLAYER_KERNEL_PROVIDER_PATH，按条件 require 上述文件:

    require ${@bb.utils.contains('DISTRO_FEATURES', 'mylayer-kernel', '${META_MYLAYER_KERNEL_PROVIDER_PATH}', '', d)}

    bb.utils.contains 详情见 lib/bb/utils.py。

    备注

    bb.utils.contains 返回空字符串时，require 按设计不会失败。

  4. 回到 layer.conf，将 meta-mylayer-cfg 加入 USER_CLASSES:

    USER_CLASSES:append = " meta-mylayer-cfg"

    该类将全局继承。但由于 require 有条件，只有 DISTRO_FEATURES 启用 mylayer-kernel 时才会产生实际影响。

相同方法也适用于 机器功能。虽然不是强制要求， 建议将 DISTRO_FEATURES 的包含文件放在层的 conf/distro/include， 将 MACHINE_FEATURES 的包含文件放在 conf/machine/include。

3 管理层

bitbake-layers 可展示多层项目的配方结构。它报告已配置层的路径和优先级， 以及 .bbappend 与对应配方，有助于发现潜在问题。

查看帮助:

$ bitbake-layers --help

可用命令如下：

  • help: 显示一般帮助或指定命令帮助。

  • show-layers: 显示当前配置的层。

  • show-overlayed: 列出被覆盖配方，即更高优先级层中存在同名配方的情况。

  • show-recipes: 列出可用配方及提供它们的层。

  • show-appends: 列出 .bbappend 及其对应配方。

  • show-cross-depends: 列出跨层配方依赖。

  • add-layer: 向 build/conf/bblayers.conf 添加层。

  • remove-layer: 从 build/conf/bblayers.conf 移除层。

  • flatten: 将层配置扁平化到独立输出目录，其中包含所有层内容，移除被 覆盖的配方，并将追加文件内容并入对应配方。可能需要手动清理：

    • 非配方文件，例如补丁，会被覆盖，命令会对此发出警告。

    • layer.conf 中超出普通层设置的内容需要处理，因为只使用最低优先级 层的 layer.conf。

    • 追加文件中的覆盖或追加项需要整理。各 .bbappend 内容会进入扁平化 配方，但追加或修改的变量值需自行清理。以下示例中，工具用 #### bbappended ... 标明后续内容来源:

      ...
DESCRIPTION = "A useful utility"
...
EXTRA_OECONF = "--enable-something"
...

#### bbappended from meta-anotherlayer ####

DESCRIPTION = "Customized utility"
EXTRA_OECONF += "--enable-somethingelse"

      理想情况下，整理为:

      ...
DESCRIPTION = "Customized utility"
...
EXTRA_OECONF = "--enable-something --enable-somethingelse"
...

  • layerindex-fetch：从层索引获取层及依赖层，并加入 build/conf/bblayers.conf。

  • layerindex-show-depends：从层索引查找依赖。

  • save-build-conf：将当前 build/conf/local.conf 和 build/conf/bblayers.conf 保存为层中的模板，以后通过 TEMPLATECONF 设置构建。详见 “创建自定义模板配置目录”。

  • create-layer：创建基础层。

  • create-layers-setup：生成配置文件或脚本，用于复现当前构建各层的目录 结构和修订版本。详见 “保存和恢复层配置”。

  • show-machines：列出当前各层提供的机器。

3 使用 bitbake-layers 脚本添加层

创建通用层后，必须加入 build/conf/bblayers.conf，让构建 系统知道该层并从中搜索元数据。

使用 bitbake-layers add-layer:

$ bitbake-layers add-layer your_layer_name

下面添加 meta-scottrif，再显示配置文件中的层：

$ bitbake-layers add-layer meta-scottrif
NOTE: Starting bitbake server...
Parsing recipes: 100% |##########################################################| Time: 0:00:49
Parsing of 1441 .bb files complete (0 cached, 1441 parsed). 2055 targets, 56 skipped, 0 masked, 0 errors.
$ bitbake-layers show-layers
NOTE: Starting bitbake server...
layer                 path                                                            priority
==============================================================================================
meta                  /home/scottrif/bitbake-builds/layers/openembedded-core/meta           5
meta-poky             /home/scottrif/bitbake-builds/layers/meta-yocto/meta-poky             5
meta-yocto-bsp        /home/scottrif/bitbake-builds/layers/meta-yocto/meta-yocto-bsp        5
workspace             /home/scottrif/bitbake-builds/build/workspace                         99
meta-scottrif         /home/scottrif/bitbake-builds/build/meta-scottrif                     6

加入该文件后，构建系统就能在构建期间定位此层。

备注

构建系统按照列表从上到下搜索层。

3 保存和恢复层配置

构建能够正常工作且层集合正确后，可以将各层名称、来源仓库和 SCM 修订版本 保存到配置文件，便于以后在原机器或其他机器复现。方法如下:

$ bitbake-layers create-layers-setup /srv/work/alex/meta-alex/
NOTE: Starting bitbake server...
NOTE: Created /srv/work/alex/meta-alex/setup-layers.json
NOTE: Created /srv/work/alex/meta-alex/setup-layers

工具需要一个参数指定输出位置。输出包括 JSON 层配置和 setup-layers 脚本，可在其他位置或主机恢复这些层。参数可指向自定义层，此时它成为必须 首先检出的“引导层”，也可以指向完全独立的位置。

恢复步骤如下：

  1. 克隆引导层或其他存放 JSON 配置和设置脚本的仓库。

  2. 不加选项直接运行脚本:

    alex@Zen2:/srv/work/alex/my-build$ meta-alex/setup-layers
Note: not checking out source meta-alex, use --force-bootstraplayer-checkout to override.

Setting up source meta-intel, revision 15.0-hardknott-3.3-310-g0a96edae, branch master
Running 'git init -q /srv/work/alex/my-build/meta-intel'
Running 'git remote remove origin > /dev/null 2>&1; git remote add origin https://git.yoctoproject.org/meta-intel' in /srv/work/alex/my-build/meta-intel
Running 'git fetch -q origin || true' in /srv/work/alex/my-build/meta-intel
Running 'git checkout -q 0a96edae609a3f48befac36af82cf1eed6786b4a' in /srv/work/alex/my-build/meta-intel

Setting up source poky, revision 4.1_M1-372-g55483d28f2, branch akanavin/setup-layers
Running 'git init -q /srv/work/alex/my-build/poky'
Running 'git remote remove origin > /dev/null 2>&1; git remote add origin https://git.yoctoproject.org/poky' in /srv/work/alex/my-build/poky
Running 'git fetch -q origin || true' in /srv/work/alex/my-build/poky
Running 'git remote remove poky-contrib > /dev/null 2>&1; git remote add poky-contrib ssh://git@push.yoctoproject.org/poky-contrib' in /srv/work/alex/my-build/poky
Running 'git fetch -q poky-contrib || true' in /srv/work/alex/my-build/poky
Running 'git checkout -q 11db0390b02acac1324e0f827beb0e2e3d0d1d63' in /srv/work/alex/my-build/poky

备注

此方法也可更新已有检出目录。

备注

脚本可独立运行，构建机器只需安装 python3 和 git。

备注

create-layers-setup 和 setup-layers 都有其他可定制行为的选项， 可通过 --help 查看。