本文档详细介绍了OpenEmbedded构建系统中的一些重要变量，如ABIEXTENSION、ALLOW_EMPTY、ALTERNATIVE_LINK_NAME等，涉及包管理、替代系统、依赖控制等多个方面。这些变量在控制软件包的构建、版本管理、命令替换等方面起到关键作用，帮助开发者理解和定制构建流程。
12变量词汇表
目录
本章列出了 OpenEmbedded 构建系统中使用的常用变量，并概述了它们的功能和内容。
A B C D E F G H I K L M N O P R S T U V W X
对 GNU 规范体系结构名称（例如“eabi”）的应用程序二进制接口 (ABI) 字段的扩展。
ABI 扩展在机器包含文件中设置。例如，该 meta/conf/machine/include/arm/arch-arm.inc文件设置了以下扩展名：
ABIEXTENSION = "eabi"
指定是否生成一个输出包，即使它是空的。默认情况下，BitBake 不会生成空包。当包的存在存在RDEPENDS或其他一些硬运行时要求时，此默认行为可能会导致问题 。
与所有包控制变量一样，您必须始终将它们与包名称覆盖结合使用，如下所示：
ALLOW_EMPTY:${PN} = "1"
ALLOW_EMPTY:${PN}-dev = "1"
ALLOW_EMPTY:${PN}-staticdev = "1"
列出包中需要备用二进制命名方案的命令。有时在多个包中提供相同的命令。发生这种情况时，OpenEmbedded 构建系统需要使用替代系统来创建不同的二进制命名方案，以便命令可以共存。
要使用该变量，请列出另一个包也提供的包命令。例如，如果busybox包有四个这样的命令，您可以按如下方式标识它们：
ALTERNATIVE:busybox = "sh sed test bracket"
有关替代系统的更多信息，请参阅“ update-alternatives.bbclass ”部分。
由替代系统使用以将重复的命令映射到实际位置。例如，如果包bracket提供的命令 busybox通过另一个包复制，则必须使用ALTERNATIVE_LINK_NAME变量指定实际位置：
ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/["
在此示例中，来自包的bracket命令（即[）的二进制文件busybox驻留在/usr/bin/.
注意
如果ALTERNATIVE_LINK_NAME未定义，则默认为${bindir}/name。
有关替代系统的更多信息，请参阅“ update-alternatives.bbclass ”部分。
由替代系统用于为重复命令创建默认优先级。您可以使用该变量来创建单个默认值，而不管命令名称或包是什么、特定重复命令的默认值（无论包如何），或者是与特定包相关的特定命令的默认值。以下是可用的语法形式：
ALTERNATIVE_PRIORITY = "priority"
ALTERNATIVE_PRIORITY[name] = "priority"
ALTERNATIVE_PRIORITY_pkg[name] = "priority"
有关替代系统的更多信息，请参阅“ update-alternatives.bbclass ”部分。
由替代系统用于为重复命令创建默认链接位置。您可以使用该变量为所有重复命令创建一个默认位置，而不管命令名称或包是什么，为特定重复命令创建一个默认位置，而不管包如何，或者为与特定包相关联的特定命令创建默认位置。以下是可用的语法形式：
ALTERNATIVE_TARGET = "target"
ALTERNATIVE_TARGET[name] = "target"
ALTERNATIVE_TARGET_pkg[name] = "target"
注意
如果未定义ALTERNATIVE_TARGET，则它从ALTERNATIVE_LINK_NAME变量继承值。
如果ALTERNATIVE_LINK_NAME和ALTERNATIVE_TARGET相同，则ALTERNATIVE_TARGET的目标会.{BPN}附加“ ”。
最后，如果引用的文件尚未重命名，则替代系统将对其进行重命名，以避免在do_install 任务中重命名替代文件，同时在必要时保留对该命令的支持。
有关替代系统的更多信息，请参阅“ update-alternatives.bbclass ”部分。
继承 features_check 类时，此变量标识分发功能列表，其中必须在当前配置中启用至少一个功能，以便 OpenEmbedded 构建系统构建配方。换句话说，如果ANY_OF_DISTRO_FEATURES 中列出的任何功能都没有出现在当前配置中的DISTRO_FEATURES中，则该配方将被跳过，如果构建系统尝试构建该配方，则会触发错误。
使用LABELS指定的每个目标的附加字符串的覆盖列表 。
有关如何使用此变量的更多信息，请参阅grub-efi类。
用于运行的最少命令和参数ar。
与存档器类一起使用时，确定用于创建已发布存档的信息类型。通过使用以下变量标志 (varflags)，您可以使用此变量创建修补源、原始源、配置源等的存档：
ARCHIVER_MODE[src] = "original" # Uses original (unpacked) source files.
ARCHIVER_MODE[src] = "patched" # Uses patched source files. This is the default.
ARCHIVER_MODE[src] = "configured" # Uses configured source files.
ARCHIVER_MODE[diff] = "1" # Uses patches between do_unpack and do_patch.
ARCHIVER_MODE[diff-exclude] ?= "file file ..." # Lists files and directories to exclude from diff.
ARCHIVER_MODE[dumpdata] = "1" # Uses environment data.
ARCHIVER_MODE[recipe] = "1" # Uses recipe and include files.
ARCHIVER_MODE[srpm] = "1" # Uses RPM package files.
有关变量如何工作的信息，请参阅源目录中的 meta/classes/archiver.bbclass文件。
运行汇编程序所需的最少命令和参数。
列出配方名称（PN值） BitBake 不会尝试构建。相反，BitBake 假设这些配方已经构建。
在 OpenEmbedded-Core 中，ASSUME_PROVIDED主要指定不应构建的原生工具。一个例子是git-native，当指定时，允许使用来自主机的 Git 二进制文件而不是构建git-native.
提供额外的shlibs提供者映射信息，它添加或覆盖系统自动提供的信息。使用空格分隔多个条目。
例如，使用以下形式shlib在 packagename 中添加可选版本的 shlibname 提供者：
shlibname:packagename[_version]
这是一个添加名为libEGL.so.1 由libegl-implementation包提供的共享库的示例：
ASSUME_SHLIBS = "libEGL.so.1:libegl-implementation"
用于联系原始作者或作者以发送补丁和转发错误的电子邮件地址。
当debian类被继承时，这是默认行为，AUTO_LIBNAME_PKGS指定应该检查哪些包的库并根据 Debian 库包命名重命名。
默认值为“${PACKAGES}”，这会导致 debian 类对配方显式生成的所有包进行操作。
启用为 syslinux 引导加载程序创建自动菜单。您必须在您的配方中设置此变量。所述 SYSLINUX类检查该变量。
当SRCREV设置为此变量的值时，它指定使用存储库中的最新源修订。下面是一个例子：
SRCREV = "${AUTOREV}"
如果您使用前面的语句来检索最新版本的软件，则需要确保PV包含 ${
SRCPV}。例如，假设您有一个继承内核类的内核配方， 并且您使用了前面的语句。在这个例子中，${SRCPV}不会自动进入PV。因此，您需要更改配方中的PV以使其包含${SRCPV}.
有关更多信息，请参阅Yocto 项目开发任务手册中的“自动递增包版本号”部分。
在COMMON_LICENSE_DIR和 LICENSE_PATH指定的目录中找到的许可证列表 。
注意
假设在 定义AVAILABLE_LICENSES之前（在license.bbclass 中）已完成对COMMON_LICENSE_DIR和 LICENSE_PATH 的所有更改。
可供 OpenEmbedded 构建系统使用的已定义 CPU 和应用程序二进制接口 (ABI) 调整（即“调整”）的列表。
该列表仅显示可用的曲调。并非所有的曲调都可能与特定的机器配置兼容，或者在Multilib 配置中彼此 兼容。
要将曲调添加到列表中，请务必使用“+=”BitBake 运算符在其后面添加空格。不要简单地使用“=”运算符替换列表。有关更多信息，请参阅BitBake 用户手册中的“基本语法”部分。
Azure 存储共享访问签名，当使用 Azure 存储提取器 (az://) 时， 可以定义此变量以供提取器用于对非公共工件进行身份验证和访问。
AZ_SAS = ""se=2021-01-01&sp=r&sv=2018-11-09&sr=c&skoid=<skoid>&sig=<signature>""
有关更多信息，请参阅 Microsoft 的 Azure 存储文档，网址为 https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview
构建目录中的目录，OpenEmbedded 构建系统在配方的构建过程中将生成的对象放置在该目录中。默认情况下，此目录与S目录相同 ，定义为：
S = "${WORKDIR}/${BP}"
您可以将 ( S ) 目录和B变量指向的目录分开。大多数基于 Autotools 的配方支持分离这些目录。构建系统默认使用单独的目录gcc和一些内核配方。
列出不安装的“仅推荐”软件包。仅推荐包是仅通过RRECOMMENDS变量安装的包 。您可以通过将它们与BAD_RECOMMENDATIONS变量一起列出来阻止安装任何这些“推荐”的软件包：
BAD_RECOMMENDATIONS = "package_name package_name package_name ..."
您可以在local.conf文件中全局设置此变量，也可以使用配方名称覆盖将其附加到特定的图像配方：
BAD_RECOMMENDATIONS:pn-target_image = "package_name"
重要的是要意识到，如果您选择不使用此变量安装包并且其他一些包依赖于它们（即列在配方的RDEPENDS 变量中），OpenEmbedded 构建系统将忽略您的请求并将安装包以避免依赖错误.
仅当使用 IPK 和 RPM 打包后端时才支持此变量。不支持 DEB。
有关相关信息，请参阅NO_RECOMMENDATIONS和 PACKAGE_EXCLUDE变量。
CPU 或应用程序二进制接口 (ABI) 调优的库目录名称。该BASE_LIB仅适用于multilib的背景。有关Multilib 的信息，请参阅 Yocto 项目开发任务手册中的“将多个版本的库文件合并为一个图像”部分。
该BASE_LIB在机器定义的变量在文件中包含源目录。如果未使用 Multilib，则该值默认为“lib”。
指向所有配方的工作目录的基础。默认值为“${TMPDIR}/work”。
指定一个以空格分隔的主机列表，允许提取程序使用这些主机来获取所需的源代码。以下是围绕此变量的注意事项：
-
此主机列表仅在BB_NO_NETWORK未设置或设置为“0”时使用。
-
对主机名开头的通配符匹配的支持有限。例如，下面的设置相匹配
git.gnu.org，ftp.gnu.org和foo.git.gnu.org。BB_ALLOWED_NETWORKS = "*.gnu.org"注意
“
*”字符的使用仅适用于主机名的开头，并且必须与主机名的其余部分隔离。您不能在名称的任何其他位置使用通配符或与名称的前部组合使用。例如，
*.foo.bar支持，而不支持*aa.foo.bar。 -
不在主机列表中的镜像将被跳过并登录到调试中。
-
尝试访问不在主机列表中的网络会导致失败。
将BB_ALLOWED_NETWORKS与PREMIRRORS结合使用 非常有用。将要使用的主机添加到PREMIRRORS 会导致从允许的位置获取源代码，并避免在SRC_URI 语句中出现不允许的主机时引发错误。这是因为在从PREMIRRORS成功获取后，获取 器不会尝试使用SRC_URI 中列出的主机。
定义 BitBake 如何处理附加文件 ( .bbappend) 没有相应配方文件 ( .bb) 的情况。这种情况经常发生在层不同步时（例如，oe-core 碰撞配方版本，旧配方不再存在，另一层尚未更新到新版本的配方）。
默认的致命行为是最安全的，因为它是在不同步的情况下的理智反应。重要的是要意识到何时不再应用您的更改。
您可以通过在local.conf位于构建目录的文件中 将此变量设置为“1”、“yes”或“true”来更改默认行为：这是一个示例：
BB_DANGLINGAPPENDS_WARNONLY = "1"
在构建期间监控磁盘空间和可用 inode，并允许您根据这些参数控制构建。
默认情况下禁用磁盘空间监控。要启用监控，请将BB_DISKMON_DIRS变量添加到您conf/local.conf在Build Directory 中找到的文件中。使用以下表格：
BB_DISKMON_DIRS = "action,dir,threshold [...]"
where:
action is:
ABORT: Immediately abort the build when
a threshold is broken.
STOPTASKS: Stop the build after the currently
executing tasks have finished when
a threshold is broken.
WARN: Issue a warning but continue the
build when a threshold is broken.
Subsequent warnings are issued as
defined by the BB_DISKMON_WARNINTERVAL
variable, which must be defined in
the conf/local.conf file.
dir is:
Any directory you choose. You can specify one or
more directories to monitor by separating the
groupings with a space. If two directories are
on the same device, only the first directory
is monitored.
threshold is:
Either the minimum available disk space,
the minimum number of free inodes, or
both. You must specify at least one. To
omit one or the other, simply omit the value.
Specify the threshold using G, M, K for Gbytes,
Mbytes, and Kbytes, respectively. If you do
not specify G, M, or K, Kbytes is assumed by
default. Do not use GB, MB, or 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 的变量conf/local.conf。此示例导致构建系统在磁盘空间${TMPDIR}低于 1 GB 或可用空闲 inode 低于 100 KB时立即中止 。由于变量提供了两个目录，因此当${SSTATE_DIR}目录中的磁盘空间低于 1 GB 或空闲 inode 数低于 100 KB时，构建系统也会发出警告。在BB_DISKMON_WARNINTERVAL 变量定义的间隔期间发出后续警告。
当${TMPDIR} 目录中的最小磁盘空间低于 1 GB时，第二个示例在所有当前正在执行的任务完成后停止构建。在这种情况下，不会对空闲 inode 进行磁盘监控。
当${TMPDIR}目录中的空闲 inode 数量低于 100 KB时，最后一个示例立即中止构建。在这种情况下，不会对目录本身进行磁盘空间监视。
定义磁盘空间和空闲 inode 警告间隔。要设置这些间隔，请conf/local.conf在Build Directory中的文件中定义变量。
如果要使用BB_DISKMON_WARNINTERVAL变量，则还必须使用BB_DISKMON_DIRS 变量并将其操作定义为“WARN”。在构建期间，每次磁盘空间或空闲 inode 数量进一步减少相应的时间间隔时，都会发出后续警告。
如果您不提供BB_DISKMON_WARNINTERVAL变量并且您确实将BB_DISKMON_DIRS与“WARN”操作一起使用，则磁盘监视间隔默认如下：
BB_DISKMON_WARNINTERVAL = "50M,5K"
在配置文件中指定变量时，请使用以下形式：
BB_DISKMON_WARNINTERVAL = "disk_space_interval,disk_inode_interval"
where:
disk_space_interval is:
An interval of memory expressed in either
G, M, or K for Gbytes, Mbytes, or Kbytes,
respectively. You cannot use GB, MB, or KB.
disk_inode_interval is:
An interval of free inodes expressed in either
G, M, or K for Gbytes, Mbytes, or Kbytes,
respectively. You cannot use GB, MB, or KB.
下面是一个例子：
BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K"
BB_DISKMON_WARNINTERVAL = "50M,5K"
这些变量会导致 OpenEmbedded 构建系统在每次可用磁盘空间进一步减少 50 MB 或目录中的空闲 inode 数量进一步减少 5 KB 时发出后续警告${SSTATE_DIR} 。每次达到超出初始警告（即 1 GB 和 100 KB）的相应间隔时，都会根据间隔发出后续警告。
导致源代码控制存储库（例如 Git 存储库）的 tarball，包括元数据，放置在 DL_DIR目录中。
出于性能原因，创建和放置这些存储库的 tarball 不是 OpenEmbedded 构建系统的默认操作。
BB_GENERATE_MIRROR_TARBALLS = "1"
local.conf在Build Directory中的文件中设置此变量 。
获得包含源文件的 tarball 后，您可以通过删除任何 Git 或其他源代码控制工作目录来清理DL_DIR目录。
BitBake 应在任一时间并行运行的最大任务数。OpenEmbedded 构建系统会自动将此变量配置为等于构建系统上的内核数。例如，具有双核处理器且也使用超线程的系统会导致BB_NUMBER_THREADS变量默认为“4”。
对于单插槽系统（即一个 CPU），您不必覆盖此变量即可在构建期间获得最佳并行度。但是，如果您有使用多个物理 CPU 的非常大的系统，您可能需要确保BB_NUMBER_THREADS变量设置不高于“20”。
有关加速构建的更多信息，请参阅Yocto 项目开发任务手册中的“加速构建”部分。
指定由于不活动而卸载 BitBake 服务器的时间（以秒为单位）。设置BB_SERVER_TIMEOUT以确定 BitBake 服务器在调用之间停留的时间。
例如，local.conf文件中的以下语句指示服务器在 20 秒不活动后卸载：
BB_SERVER_TIMEOUT = "20"
如果您希望服务器永远不会被卸载，请将BB_SERVER_TIMEOUT设置为“-1”。
允许您扩展配方，以便它构建软件的变体。有一些常见的配方变体作为“本地”，例如 quilt-native，它是为在构建系统上运行而构建的 Quilt 副本；“交叉”，例如gcc-cross，它是一个编译器，用于在构建机器上运行，但生成在目标机器上运行的二进制文件 ；“nativesdk”，它针对的是 SDK 机器而不是MACHINE；和“ multilib:multilib_name”形式的“ multilibs”。
要使用最少的代码构建不同的配方变体，通常只需将以下内容添加到您的配方中：
BBCLASSEXTEND =+ "native nativesdk"
BBCLASSEXTEND =+ "multilib:multilib_name"
注意
在内部，BBCLASSEXTEND机制通过重写变量值和应用诸如:class-native. 例如，要产生一个配方的原生版本，一个DEPENDS的“foo”被改写为DEPENDS上的“福原生”。
即使使用BBCLASSEXTEND，配方也只解析一次。解析一次会增加一些限制。例如，不可能根据变体包含不同的文件，因为include在解析配方时会处理语句。
列出已配置层的名称。这些名称用于查找其他BBFILE_*变量。通常，每个层都会将其名称附加到其conf/layer.conf文件中的此变量。
扩展以匹配特定层中来自BBFILES 的文件的变量 。该变量在conf/layer.conf文件中使用，并且必须以特定层的名称作为后缀（例如BBFILE_PATTERN_emenlow）。
为每一层中的配方文件分配优先级。
此变量在同一配方出现在多个层中的情况下很有用。设置此变量允许您将一个层与包含相同配方的其他层进行优先级排序 - 有效地让您控制多个层的优先级。无论配方的版本如何（PV变量），通过此变量建立的优先级都有效。例如，具有较高PV值的配方但其BBFILE_PRIORITY设置为具有较低优先级的层仍然具有较低的优先级。
BBFILE_PRIORITY变量的值越大，优先级越高。例如，值 6 的优先级高于值 5。 如果未指定，则BBFILE_PRIORITY变量基于层依赖项设置（有关更多信息，请参阅LAYERDEPENDS变量。默认优先级，如果未指定对于没有依赖项的层，是定义的最低优先级 + 1（如果未定义优先级，则为 1）。
提示
您可以使用该命令 列出所有已配置的层及其优先级。bitbake-layers show-layers
BitBake 用于构建软件的以空格分隔的配方文件列表。
指定配方文件时，您可以使用 Python 的glob语法进行模式匹配 。有关语法的详细信息，请按照上一个链接查看文档。
当识别的层存在时激活内容。您可以通过层定义的集合来标识层。
使用BBFILES_DYNAMIC变量可避免.bbappend文件所在.bb的层中的相应文件试图通过修改其他层.bbappend但不想引入对这些其他层的硬依赖关系。
对BBFILES_DYNAMIC使用以下形式： collection_name:filename_pattern 以下示例标识两个集合名称和两个文件名模式：
BBFILES_DYNAMIC += " \
clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \
core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \
"
下一个示例显示了由于找到无效条目而发生的错误消息，这会导致解析中止：
ERROR: BBFILES_DYNAMIC entries must be of the form <collection name>:<filename pattern>, not:
/work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend
/work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend
控制 BitBake 如何在构建失败时显示日志的变量。
如果设置了BBINCLUDELOGS，则指定在报告失败任务时要打印的任务日志文件中的最大行数。如果不设置BBINCLUDELOGS_LINES，则打印整个日志。
列出要在构建期间启用的层。该变量bblayers.conf在Build Directory的配置文件中定义。下面是一个例子：
BBLAYERS = " \
/home/scottrif/poky/meta \
/home/scottrif/poky/meta-poky \
/home/scottrif/poky/meta-yocto-bsp \
/home/scottrif/poky/meta-mykernel \
"
此示例启用四个图层，其中一个是名为 的自定义用户定义图层meta-mykernel。
防止 BitBake 处理配方和配方附加文件。
您可以使用BBMASK变量来“隐藏”这些.bb和 .bbappend文件。BitBake 忽略与任何表达式匹配的任何配方或配方附加文件。就好像 BitBake 根本没有看到它们一样。因此，BitBake 不会解析或以其他方式使用匹配文件。
您提供的值将传递给 Python 的正则表达式编译器。因此，语法遵循 Python 的正则表达式 (re) 语法。将表达式与文件的完整路径进行比较。有关完整的语法信息，请参阅https://docs.python.org/3/library/re.html#regular-expression-syntax 上的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 += "/meta-foo/.*/openldap"
BBMASK += "opencv.*\.bbappend"
BBMASK += "lzma"
注意
指定目录名称时，请使用尾部斜杠字符以确保仅匹配该目录名称。
在构建具有多个配置的目标时，指定每个额外的单独配置。在您的conf/local.conf配置文件中使用此变量。为您使用的每个配置文件指定一个 multiconfigname。例如，下面这行指定了三个配置文件：
BBMULTICONFIG = "configA configB configC"
您使用的每个配置文件都必须位于Build Directory conf/multiconfig目录中（例如 build_directory /conf/multiconfig/configA.conf）。
有关如何在支持使用多个配置构建目标的环境中使用BBMULTICONFIG 的信息，请参阅Yocto 项目开发任务手册中的“使用多个配置为多个目标构建映像”部分。
BitBake 使用它来定位.bbclass和配置文件。这个变量类似于PATH变量。
注意
如果您从Build Directory之外的目录运行 BitBake ，则必须确保将BBPATH设置 为指向 Build Directory。像设置任何环境变量一样设置变量，然后运行 BitBake：
$ BBPATH = "build_directory"
$ export BBPATH
$ bitbake target
如果在 BitBake 环境中定义，BBSERVER指向 BitBake 远程服务器。
使用以下格式将变量导出到 BitBake 环境：
export BBSERVER=localhost:$port
默认情况下，BBSERVER也出现在BB_HASHBASE_WHITELIST 中。因此，BBSERVER被排除在校验和和相关性数据之外。
继承 binconfig-disabled类时，此变量指定要禁用的二进制配置脚本，以支持pkg-config用于查询信息。该 binconfig-disabled班将修改指定的脚本返回一个错误，从而对他们的呼叫可以很容易地找到和替换。
要添加多个脚本，请用空格分隔它们。这是libpng食谱中的一个例子：
BINCONFIG = "${bindir}/libpng-config ${bindir}/libpng16-config"
继承binconfig类时，此变量为需要编辑的配置脚本指定通配符。脚本被编辑以更正在编译期间设置的任何路径，以便它们在安装到 sysroot 并被其他配方的构建过程调用时正确使用。
注意
所述BINCONFIG_GLOB可变用途 壳通配，这是识别和通配符的扩充模式匹配过程中。Shell globbing 与fnmatch 和glob非常相似 。
有关此变量是如何工作的详情，请参阅 meta/classes/binconfig.bbclass在源目录。您还可以在“ binconfig.bbclass ”部分找到有关该类的一般信息。
基本配方名称和版本，但没有任何特殊配方名称后缀（即-native，，lib64-等等）。BP由以下部分组成：
${BPN}-${PV}
该变量是一个版本的PN去除常见的前缀和后缀，如变量nativesdk-， -cross，-native，和的multilib的lib64-和lib32-。去除前缀和后缀的列表确切由指定 MLPREFIX和 SPECIAL_PKGSUFFIX变量分别。
指定配方的上游错误跟踪网站的 URL。OpenEmbedded 构建系统不使用此变量。相反，该变量是一个有用的指针，以防需要手动报告正在构建的软件中的错误。
指定构建主机的体系结构（例如i686）。OpenEmbedded 构建系统根据命令报告的机器名称设置BUILD_ARCH的值uname。
为构建主机指定特定于体系结构的汇编器标志。默认情况下，BUILD_AS_ARCH 的值为空。
为构建主机指定特定于体系结构的 C 编译器标志。默认情况下，BUILD_CC_ARCH 的值为空。
指定将 C 编译器用作链接器时要用于构建主机的链接器命令。默认情况下，BUILD_CCLD 指向 GCC 并将BUILD_CC_ARCH的值作为参数传递 ，假设 BUILD_CC_ARCH已设置。
指定在为构建主机构建时传递给 C 编译器的标志。在-native上下文中构建时， CFLAGS默认设置为该变量的值。
指定在为构建主机构建时传递给 C 预处理器（即传递给 C 和 C++ 编译器）的标志。在-native上下文中构建时，CPPFLAGS 默认设置为此变量的值。
指定在为构建主机构建时传递给 C++ 编译器的标志。在-native上下文中构建时， CXXFLAGS默认设置为该变量的值。
为构建主机指定 Fortran 编译器命令。默认情况下，BUILD_FC指向Gfortran并传递作为参数的值BUILD_CC_ARCH，假定 BUILD_CC_ARCH被设置。
指定构建主机的链接器命令。默认情况下， BUILD_LD指向 GNU 链接器 (ld) 并将BUILD_LD_ARCH的值作为参数传递，假设 BUILD_LD_ARCH已设置。
为构建主机指定特定于体系结构的链接器标志。默认情况下，BUILD_LD_ARCH 的值为空。
指定在为构建主机构建时传递给链接器的标志。在-native上下文中构建时， LDFLAGS默认设置为该变量的值。
指定在为构建主机或 SDK 构建时传递给 C 编译器的优化标志。这些标志通过BUILD_CFLAGS和 BUILDSDK_CFLAGS默认值传递。
BUILD_OPTIMIZATION变量的默认值是“-O2 -pipe”。
指定构建主机上使用的操作系统（例如“linux”）。OpenEmbedded 构建系统根据命令报告的操作系统设置BUILD_OS的值 uname- 第一个单词，转换为小写字符。
用于本机配方的工具链二进制前缀。OpenEmbedded 构建系统在构建配方时 使用BUILD_PREFIX值来设置 TARGET_PREFIXnative。
指定用于从为构建主机生成的二进制文件中去除调试符号的命令。默认情况下，BUILD_STRIP 指向 ${
BUILD_PREFIX}strip。
指定在为构建主机构建时（即构建native配方时）使用的系统，包括体系结构和操作系统 。
OpenEmbedded 构建系统会根据BUILD_ARCH、 BUILD_VENDOR和 BUILD_OS自动设置此变量。您不需要自己设置 BUILD_SYS变量。
指定为构建主机构建时要使用的供应商名称。默认值为空字符串 (“”)。
指向构建目录的位置。您可以通过oe-init-build-env脚本通过在运行脚本时传入构建目录路径来间接定义此目录 。如果您运行该脚本并且不提供构建目录路径，则BUILDDIR默认 build在当前目录中。
继承buildhistory 类时，此变量指定是否在本地 Git 存储库中提交构建历史记录输出。如果设置为“1”，这个本地存储库将由buildhistory 类自动维护，并且将在每次构建时创建一个提交，以更改构建历史输出（图像、包和 sdk）的每个顶级子目录。如果要跟踪随时间推移构建历史记录的更改，则应将此值设置为“1”。
默认情况下，buildhistory该类不会在本地 Git 存储库中提交构建历史输出：
BUILDHISTORY_COMMIT ?= "0"
继承buildhistory 类时，此变量指定要用于每个 Git 提交的作者。为了使BUILDHISTORY_COMMIT_AUTHOR变量起作用， 必须将BUILDHISTORY_COMMIT变量设置为“1”。
Git 要求您为BUILDHISTORY_COMMIT_AUTHOR变量提供的值 采用“name email @ host ”的形式。提供无效的电子邮件地址或主机不会产生错误。
默认情况下，buildhistory类设置变量如下：
BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory <buildhistory@${DISTRO}>"
继承buildhistory 类时，此变量指定保存构建历史信息的目录。有关变量如何工作的更多信息，请参阅buildhistory.class.
默认情况下，buildhistory类设置目录如下：
BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory"
继承buildhistory 类时，此变量指定要启用的构建历史功能。有关构建历史如何工作的更多信息，请参阅Yocto 项目开发任务手册中的“维护构建输出质量”部分。
您可以以空格分隔列表的形式指定这些功能：
-
image：对图像内容的分析，其中包括已安装包的列表等。
-
包：分析单个包的内容。
-
sdk：软件开发包（SDK）内容解析。
-
任务：保存共享状态 （sstate）任务的输出文件签名 。这将为每个任务保存一个文件，并列出每个暂存文件（即任务的输出）的 SHA-256 校验和。
默认情况下，buildhistory该类启用以下功能：
BUILDHISTORY_FEATURES ?= "image package sdk"
在继承buildhistory 类时，该变量指定了从镜像内容复制到镜像目录中“image-files”目录下的构建历史目录中的文件的路径列表，以便您可以跟踪每个文件的内容. 默认是复制 /etc/passwd和/etc/group，它允许您监视用户和组条目的更改。您可以修改列表以包含任何文件。指定无效路径不会产生错误。因此，您可以包含可能不总是存在的文件。
默认情况下，buildhistory该类提供以下文件的路径：
BUILDHISTORY_IMAGE_FILES ?= "/etc/passwd /etc/group"
BUILDHISTORY_PATH_PREFIX_STRIP
继承buildhistory 类时，此变量指定一个公共路径前缀，当该task功能在BUILDHISTORY_FEATURES 中处于活动状态时，应从任务签名列表中的路径开头删除该前缀 。当构建历史从多个来源填充时，这可能很有用，这些来源可能不都使用相同的顶级目录。
默认情况下，buildhistory类设置变量如下：
BUILDHISTORY_PATH_PREFIX_STRIP ?= ""
在这种情况下，不会剥离任何前缀。
当继承buildhistory 类时，这个变量可以选择指定一个远程存储库，构建历史将 Git 更改推送到该存储库。为了使 BUILDHISTORY_PUSH_REPO工作， BUILDHISTORY_COMMIT必须设置为“1”。
存储库应对应于指定 Git 理解的存储库的远程地址，或者对应于您在本地存储库中手动设置的远程名称。git remote
默认情况下，buildhistory类设置变量如下：
BUILDHISTORY_PUSH_REPO ?= ""
指定在为 SDK 构建时传递给 C 编译器的标志。在nativesdk-上下文中构建时， CFLAGS默认设置为该变量的值。
指定在为 SDK 构建时传递给 C 预处理器（即传递给 C 和 C++ 编译器）的标志。在nativesdk-上下文中构建时，CPPFLAGS默认设置为此变量的值。
指定在为 SDK 构建时传递给 C++ 编译器的标志。在nativesdk-上下文中构建时， CXXFLAGS默认设置为该变量的值。
指定在为 SDK 构建时传递给链接器的标志。在nativesdk-上下文中构建时， LDFLAGS默认设置为该变量的值。
指向在您使用和启用buildstats类时保存构建统计信息的目录的位置 。该 BUILDSTATS_BASE目录默认为 ${
TMPDIR}/buildstats/。
对于 BusyBox 配方，指定是否将输出可执行文件分成两部分：一部分用于需要的功能， 另一部分用于其余功能（即不需要的功能）。setuid rootsetuid root
所述BUSYBOX_SPLIT_SUID变量默认为“1”，这导致分离的输出可执行文件。将变量设置为“0”以获取单个输出可执行文件。
指定 BitBake 用于存储元数据缓存的目录， 因此无需在每次启动 BitBake 时对其进行解析。
用于运行 C 编译器的最少命令和参数。
指定要传递给 C 编译器的标志。该变量被导出到环境变量中，因此在编译步骤中对正在构建的软件可见。
CFLAGS 的默认初始化取决于正在构建的内容：
-
为目标构建时的TARGET_CFLAGS
-
BUILD_CFLAGS为构建主机构建时（即
-native） -
为 SDK构建时的BUILDSDK_CFLAGS（即
nativesdk-）
一个内部变量，指定当前应该应用的特殊类覆盖（例如“class-target”、“class-native”等等）。使用此变量的类（例如 native、 nativesdk等）将变量设置为适当的值。
注意
CLASSOVERRIDE从bitbake.conf文件中获取其默认的“class-target”值 。
例如，以下覆盖允许您安装额外的文件，但仅限于为目标构建时：
do_install:append:class-target() {
install my-extra-file ${D}${sysconfdir}
}
这是一个示例，FOO在为构建主机构建时设置为“native”，在不为构建主机构建时设置为“other”：
FOO:class-native = "native"
FOO = "other"
CLASSOVERRIDE背后的底层机制很简单，它包含在OVERRIDES的默认值中 。
如果在配方中设置为“1”，则CLEANBROKEN指定该 命令不适用于正在构建的软件。因此，OpenEmbedded 构建系统不会在do_configure 任务期间尝试运行 ，这是默认行为。make cleanmake clean
提供在MACHINE_FEATURES和 DISTRO_FEATURES中启用的硬件功能列表 。此选择的功能列表包含在机器和分发配置级别进行控制的有意义的功能。例如，“蓝牙”功能需要硬件支持，但在分发级别也应该是可选的，以防硬件支持蓝牙但您不打算使用它。
点meta/files/common-licenses在 源目录，这也正是通用许可文件驻留。
解析为一个或多个主机（当配方为原生时）或一个或多个目标（当配方为非原生时）与配方兼容的正则表达式。正则表达式与HOST_SYS匹配。您可以使用该变量来阻止为配方不兼容的系统类别构建配方。停止这些构建对于内核特别有用。该变量还有助于提高解析速度，因为构建系统会跳过与当前系统不兼容的解析配方。
解析为一个或多个与配方兼容的目标机器的正则表达式。正则表达式与MACHINEOVERRIDES匹配。您可以使用该变量来停止为配方不兼容的机器构建配方。停止这些构建对于内核特别有用。该变量还有助于提高解析速度，因为构建系统会跳过与当前机器不兼容的解析配方。
在为映像中显式（或隐式）安装的所有软件包安装补充软件包列表时，定义要匹配的通配符。
注意
所述COMPLEMENTARY_GLOB变量使用的Unix文件名模式匹配（的fnmatch），这是类似于Unix风格路径图案膨胀（水珠）。
生成的补充包列表与可以添加到IMAGE_FEATURES的项目相关联 。一个示例用法是“dev-pkgs”项，当添加到IMAGE_FEATURES 时， 将为映像中的每个包安装 -dev 包（包含头文件和其他开发文件）。
要添加指向通配符的新功能项，请使用变量标志指定功能项名称并使用值指定通配符。下面是一个例子：
COMPLEMENTARY_GLOB[dev-pkgs] = '*-dev'
存储每个配方的 sysroot 组件。OpenEmbedded 构建系统在为其他配方构建特定于配方的系统根时使用COMPONENTS_DIR。
默认值为“ ${
STAGING_DIR ”}-components。（即“ ${
TMPDIR}/sysroots-components ”）。
跟踪本地配置文件（即 local.conf）的版本。每次兼容性更改时，CONF_VERSION的值都会增加 build/conf/。
标识作为包一部分的可编辑或可配置文件。如果包管理系统 (PMS) 用于更新目标系统上的包，则可能会覆盖您在原始安装后更改的配置文件以及您现在希望保持不变的配置文件。换句话说，包中可能存在您不希望在包更新过程中重置的可编辑文件。您可以使用CONFFILES 变量列出包中您希望防止 PMS 在此更新过程中覆盖的文件。
要使用CONFFILES变量，请提供标识生成的包的包名称覆盖。然后，提供以空格分隔的文件列表。下面是一个例子：
CONFFILES:${PN} += "${sysconfdir}/file1 \
${sysconfdir}/file2 ${sysconfdir}/file3"
CONFFILES和FILES 变量之间存在关系。CONFFILES 中列出的文件必须是FILES 中列出的文件的子集。因为您随CONFFILES提供的配置文件只是被标识以便 PMS 不会覆盖它们，所以这些文件必须已经通过FILES 变量作为包的一部分包含在内是有道理的。
注意
将路径指定为CONFFILES变量的一部分时，最好使用适当的路径变量。例如，${sysconfdir}而不是/etc或${bindir} 而不是/usr/bin。您可以meta/conf/bitbake.conf在源目录中的文件 顶部找到这些变量的列表。
标识初始 RAM 文件系统 (initramfs) 源文件。OpenEmbedded 构建系统接收并使用此内核 Kconfig 变量作为环境变量。默认情况下，该变量设置为空（“”）。
该CONFIG_INITRAMFS_SOURCE可以是一个单一的cpio归档.cpio后缀或目录和文件的建设的initramfs镜像空格分隔的列表。cpio 存档应包含用作 initramfs 映像的文件系统存档。目录应包含要包含在 initramfs 映像中的文件系统布局。文件应根据usr/gen_init_cpio内核树中程序描述的格式包含条目。
如果您指定多个目录和文件，则 initramfs 映像将是所有目录和文件的集合。
有关创建 initramfs 的信息，请参阅Yocto 项目开发任务手册中的“构建初始 RAM 文件系统 (initramfs) 映像”部分。
包含autoconf与当前构建相关的测试结果的文件列表。Autotools 实用程序在运行时使用此变量configure。
GNU 配置的最小参数。
继承 features_check 类时，此变量标识了在构建配方时会发生冲突的分布特征。换句话说，如果 CONFLICT_DISTRO_FEATURES变量列出了在当前配置中也出现在DISTRO_FEATURES中的功能，则该配方将被跳过，如果构建系统尝试构建该配方，则会触发错误。
要从归档程序类归档的源中排除的以空格分隔的许可证列表。换句话说，如果配方的LICENSE值中的 许可证在COPYLEFT_LICENSE_EXCLUDE的值中 ，则该类不会归档其源。
注意
COPYLEFT_LICENSE_EXCLUDE的默认值“CLOSED Proprietary” 由copyleft_filter类设置， 该类由archiver该类继承。
要包含在归档程序类归档的源中的以空格分隔的许可证列表。换句话说，如果配方的LICENSE 值中的许可证在COPYLEFT_LICENSE_INCLUDE的值中，则其源由类存档。
默认值由copyleft_filter类设置， 该类继承自archiver该类。默认值包括“GPL*”、“LGPL*”和“AGPL*”。
要在存档器类存档的源中排除的配方列表 。所述 COPYLEFT_PN_EXCLUDE变量覆盖通过引起许可证纳入和排除 COPYLEFT_LICENSE_INCLUDE和 COPYLEFT_LICENSE_EXCLUDE 分别变量。
COPYLEFT_PN_EXCLUDE的默认值是“”，表示不按名称显式排除任何配方，由该类继承的copyleft_filter类设置 archiver。
要包含在存档器类存档的源中的配方列表 。所述 COPYLEFT_PN_INCLUDE变量覆盖通过引起许可证纳入和排除 COPYLEFT_LICENSE_INCLUDE和 COPYLEFT_LICENSE_EXCLUDE 分别变量。
COPYLEFT_PN_INCLUDE的默认值是“”，表示不按名称显式包含任何配方，由copyleft_filter类设置， 该类由archiver该类继承。
要包含在归档程序类归档的源中的以空格分隔的配方类型列表。配方类型target，native，nativesdk，cross， crosssdk，和cross-canadian。
COPYLEFT_RECIPE_TYPES的默认值“target*” 由copyleft_filter 类设置，该类由archiver该类继承。
如果将COPY_LIC_MANIFEST变量和COPY_LIC_MANIFEST变量一起设置为“1” ，则 OpenEmbedded 构建系统会将位于 中/usr/share/common-licenses的每个包的许可证文件复制到映像中。在构建期间，许可证文件放置在映像本身的目录中。
注意
该COPY_LIC_DIRS不添加对新安装的软件包许可证的图像，这可能是最适合无法升级只读文件系统提供了一个路径。有关其他信息，请参阅 LICENSE_CREATE_PACKAGE变量。您还可以参考Yocto 项目开发任务手册中的“提供许可文本”部分，了解有关提供许可文本的信息。
如果设置为“1”，则 OpenEmbedded 构建系统/usr/share/common-licenses/license.manifest会在构建期间将映像的许可证清单复制到 映像本身中。
注意
该COPY_LIC_MANIFEST不添加对新安装的软件包许可证的图像，这可能是最适合无法升级只读文件系统提供了一个路径。有关其他信息，请参阅 LICENSE_CREATE_PACKAGE变量。您还可以参考Yocto 项目开发任务手册中的“提供许可文本”部分，了解有关提供许可文本的信息。
指定要添加到映像的包列表。您应该只local.conf在Build Directory中的配置文件中设置此变量。
此变量替换POKY_EXTRA_INSTALL不再受支持的 。
指定 OpenEmbedded-Core 元数据层（即meta）的父目录。
COREBASE指向该层的父级而不是层本身，这是一个重要的区别。考虑一个示例，您克隆了 Poky Git 存储库并保留了存储库poky本地副本的名称。在这种情况下，COREBASE 指向poky文件夹，因为它是poky/meta图层的父目录。
列出COREBASE目录中应复制的文件，而不是bblayers.conf文件中列出的图层 。该COREBASE_FILES变量允许从OpenEmbedded构建系统复制元数据到可扩展SDK。
需要在COREBASE 中明确列出文件，因为它通常包含构建目录和其他通常不应复制到可扩展 SDK 中的文件。因此，使用COREBASE_FILES的值是为了仅复制实际需要的文件。
用于运行 C 预处理器的最少命令和参数。
指定要传递给 C 预处理器（即传递给 C 和 C++ 编译器）的标志。该变量被导出到环境变量中，因此在编译步骤中对正在构建的软件可见。
CPPFLAGS 的默认初始化取决于正在构建的内容：
-
为目标构建时的TARGET_CPPFLAGS
-
BUILD_CPPFLAGS为构建主机构建时（即
-native） -
为 SDK构建时的BUILDSDK_CPPFLAGS（即
nativesdk-）
目标工具的工具链二进制前缀。的 CROSS_COMPILE变量是相同 TARGET_PREFIX变量。
注意
OpenEmbedded 构建系统 仅在特定上下文中设置CROSS_COMPILE变量（例如，在构建内核和内核模块配方时）。
忽略 CVE（常见漏洞和暴露）的包名称 ( PN )列表。
被忽略的 CVE ID 列表。这是Python3 食谱中的一个示例：
# This is windows only issue.
CVE_CHECK_WHITELIST += "CVE-2020-15523"
在配方中，定义用于将配方名称与上游NIST CVE 数据库中的名称进行匹配的名称。
默认值为 ${ BPN }。如果与NIST CVE数据库中的名称不匹配或与数据库中的多个条目匹配，则需要更改默认值。
这是Berkeley DB 配方中的一个示例：
CVE_PRODUCT = "oracle_berkeley_db berkeley_db"
CVS系统下检出的文件存放的目录。
用于运行 C++ 编译器的最少命令和参数。
指定要传递给 C++ 编译器的标志。该变量被导出到环境变量中，因此在编译步骤中对正在构建的软件可见。
CXXFLAGS 的默认初始化取决于正在构建的内容：
-
为目标构建时的TARGET_CXXFLAGS
-
BUILD_CXXFLAGS为构建主机构建时（即
-native） -
为 SDK构建时的BUILDSDK_CXXFLAGS（即
nativesdk-）
目标目录。构建目录 中do_install任务安装组件 的位置。此位置默认为：
${WORKDIR}/image
注意
从此目录读取或写入的任务应在fakeroot下运行 。
构建开始的日期。日期使用年、月、日 (YMD) 格式显示（例如，“20150209”表示 2015 年 2 月 9 日）。
当前构建开始的日期和时间。该格式适用于时间戳。
当debian类被继承时，这是默认行为，DEBIAN_NOAUTONAME指定不应根据 Debian 库包命名重命名特定包。设置此变量时，您必须使用包名称作为覆盖。这是fontconfig食谱中的一个例子：
DEBIAN_NOAUTONAME:fontconfig-utils = "1"
当debian类被继承时，这是默认行为，DEBIANNAME允许您覆盖单个包的库名称。在这些情况下覆盖库名称很少见。设置此变量时，您必须使用包名称作为覆盖。这是dbus食谱中的一个例子 ：
DEBIANNAME:${PN} = "dbus-1"
指定构建带有调试信息的包。这会影响SELECTED_OPTIMIZATION变量的值。
编译系统进行调试时传入TARGET_CFLAGS和CFLAGS的选项。此变量默认为“-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe”。
指定配方选择优先级的弱偏差。
这个变量的最常见用法是在一个软件的开发版本的配方中将其设置为“-1”。在没有使用PREFERRED_VERSION来构建开发版本的情况下，以这种方式使用变量会导致默认情况下构建稳定版本的配方。
注意
DEFAULT_PREFERENCE提供的偏差很弱，如果该变量在包含相同配方的不同版本的两个层之间不同，则由BBFILE_PRIORITY覆盖。
OpenEmbedded 构建系统使用的默认 CPU 和应用程序二进制接口 (ABI) 调整（即“调整”）。该 DEFAULTTUNE帮助定义 TUNE_FEATURES。
默认调整是由机器 ( MACHINE )隐式或显式设置的。但是，您可以使用AVAILTUES定义的可用曲调覆盖设置 。
列出配方的构建时依赖项。这些依赖于其他配方，在构建时配方需要其内容（例如头文件和共享库）。
例如，考虑一个foo包含以下分配的配方：
DEPENDS = "bar"
先前分配的实际效果是，到运行do_configure任务时，由 bar 安装的所有文件都将在STAGING_DIR*变量 给定的适当暂存 sysroot 中可用foo。这种机制是通过do_configure依赖DEPENDS中列出的每个配方的do_populate_sysroot任务来实现的，通过基类中的 [deptask] 声明。
注意
很少需要 显式引用，例如，STAGING_DIR_HOST。标准类和与构建相关的变量被配置为自动使用适当的暂存系统根。
作为另一个示例，DEPENDS还可用于添加在构建期间在构建机器上运行的实用程序。例如，使用由配方构建的代码生成器的配方codegen 可能具有以下内容：
DEPENDS = "codegen-native"
有关更多信息，请参阅本机类和EXTRANATIVEPATH变量。
注意
-
DEPENDS是一个配方名称列表。或者，更准确地说，它是一个PROVIDES名称列表，通常与配方名称匹配。在DEPENDS中放置诸如“foo-dev”之类的包名是没有意义的。使用“富”，而不是，因为这将从所有组成包放文件
foo，其中包括那些从foo-dev，到SYSROOT。 -
一个配方在DEPENDS中具有另一个配方本身不会在两个配方生成的包之间添加任何运行时依赖项。但是，正如Yocto 项目概述和概念手册中的“自动添加运行时依赖项”部分所解释的，运行时依赖项通常会自动添加，这意味着对于大多数配方来说，仅依赖 DEPENDS就足够了。
-
与直觉相反，即使对于安装预编译组件的配方，DEPENDS通常也是必需的。例如，如果
libfoo是一个链接到 的预编译库libbar，那么链接到libfoo需要libfoo和都libbar在 sysroot 中可用。如果没有从安装 的配方到安装的配方的DEPENDS，其他配方可能无法链接。libfoolibbarlibfoo
有关运行时依赖项的信息，请参阅 RDEPENDS变量。您还可以查看BitBake 用户手册中的“任务”和“依赖项”部分，以获取有关任务和依赖项的更多信息。
指向 OpenEmbedded 构建系统用来放置图像、包、SDK 和其他准备在构建系统外部使用的输出文件的一般区域。默认情况下，这个目录所在的中建目录为 ${TMPDIR}/deploy。
有关构建目录结构的更多信息，请参阅“构建目录 - build/ ”部分。有关deploy目录内容的更多详细信息，请参阅Yocto 项目概述和概念手册中的“图像”、“包源”和“应用程序开发 SDK ”部分。
指向 OpenEmbedded 构建系统用来放置准备在构建系统之外使用的 Debian 软件包的区域。此变量仅在PACKAGE_CLASSES包含“package_deb”时适用 。
所述BitBake的配置文件最初定义 DEPLOY_DIR_DEB变量的子文件夹 DEPLOY_DIR：
DEPLOY_DIR_DEB = "${DEPLOY_DIR}/deb"
该package_deb类使用 DEPLOY_DIR_DEB变量，以确保 do_package_write_deb任务写入Debian软件包到相应的文件夹。有关打包工作原理的更多信息，请参阅Yocto 项目概述和概念手册中的“包源”部分。
指向 OpenEmbedded 构建系统用来放置准备部署到目标机器上的图像和其他相关输出文件的区域。该目录是特定于机器的，因为它包含${MACHINE}名称。默认情况下，这个目录所在的中建目录为 ${DEPLOY_DIR}/images/${MACHINE}/。
部署文件时，不得直接在配方中使用它。相反，它仅在配方需要“读取”已由依赖项部署的文件时才有用。所以，它应该由deploy类填充 DEPLOYDIR的内容或由image类填充IMGDEPLOYDIR的内容。
有关构建目录结构的更多信息，请参阅“构建目录 - build/ ”部分。有关deploy目录内容的更多详细信息，请参阅Yocto 项目概述和概念手册中的“
最低0.47元/天 解锁文章
358
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
