Bitbake

以下所有内容来自bitbake user manual:
http://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html .

Bitbake介绍

从根本上说，BitBake是一个通用的任务执行引擎，BitBake允许shell和Python任务在复杂的任务间依赖关系的约束条件下有效地并行运行。 BitBake的主要用户之一是OpenEmbedded，OpenEmbedded使用Bitbake以及面向任务的方法构建嵌入式Linux软件堆栈。

从概念上来说，BitBake在某些方面与GNU Make类似，但是也有明显的区别：
　　1.BitBake根据构建任务时提供的元数据来执行任务。元数据存储在配方文件（.bb）以及与配方相关的“append”（.bbappend）文件，配置文件（.conf），底层include（.inc）文件，类（.bbclass）文件中。元数据为BitBake提供有关运行哪些任务以及这些任务之间的依赖关系的指示。
　　2. BitBake包含用于从诸如本地文件，源控制系统或网站等各种地方获取源代码的源代码获取库。
　　3.用于构建的每个单元（例如，一段软件）的指示被称为“配方（recipe）”文件，配方文件包含关于该单元的所有信息（依赖性，源文件位置，校验和，描述等）。
　　4.BitBake包括客户端/服务器的抽象，可以从命令行使用或用作XML-RPC上的服务，并具有多个不同的用户界面。

配方（Recipe）

文件扩展名为.bb的BitBake配方文件是最基本的元数据文件。这些配方文件为BitBake提供以下内容：
　　（1）关于软件包的描述性信息（作者，主页，许可证等）
　　（2）配方的版本
　　（3）现有的依赖（构建和运行时依赖）
　　（4）源代码位置以及如何获取它
　　（5）源代码是否需要任何补丁，在哪里找到补丁以及如何应用补丁
　　（6）如何配置和编译源代码
　　（7）如何目标机器上安装一个或多个软件包
在BitBake或任何使用BitBake作为其构建系统的项目中，具有.bb扩展名的文件称为配方。

配置文件（Configuration Files）

配置文件（由.conf扩展名表示）定义了各种管理项目构建过程的配置变量。 这些文件分为几个部分，包括机器配置选项，分发配置选项，编译器调整选项，通用公共配置选项和用户配置选项。 主配置文件是bitbake.conf文件，它位于BitBake源码树conf目录中。

类（Classes）

类文件（由.bbclass扩展名指示）包含可以在元数据文件之间共享的有用信息。 BitBake源代码树目前带有一个名为base.bbclass的类元数据文件。您可以在classes目录中找到此文件。 base.bbclass类文件的特殊之处在于它总是自动包含在所有配方和类中。 类文件包含标准的基本任务的定义，例如获取源代码，解包，配置（默认为空），编译（运行存在的任何Makefile），安装（默认为空）和打包（默认为空）。 这些任务通常被项目开发过程中添加的其他类文件覆盖或扩展。
BitBake允许通过include文件（.inc）和类文件（.bbclass）共享元数据。例如，假设您有一个常用功能，比如要在多个recipe之间共享的任务。在这种情况下，创建包含公共功能的.bbclass文件，然后在配方中使用inherit指令继承类是共享任务的常用方法。
BitBake提供的相应的机制，允许您在配方之间共享功能。 具体来说，机制包括include，inherit，INHERIT和require指令。

include文件（.inc）

Include文件也是用于在元数据文件之间共享元数据。

附加文件(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
如果busybox的配方更新为busybox_1.3.0.bb，则附加文件名称将不匹配。但是，如果你命名了附加文件为busybox_1.％.bbappend，那么你将会依然匹配busybox_1.3.0.bb文件。
在通常情况下，您可以将附加文件命名为busybox _％.bbappend。这样简单，完全独立于版本。

Bitbake 文件介绍。

下面以bluez5.inc文件为例来说明

SUMMARY = "Linux Bluetooth Stack Userland V5"
DESCRIPTION = "Linux Bluetooth stack V5 userland components.  These include a system configurations, daemons, tools and system libraries."
HOMEPAGE = "http://www.bluez.org"
SECTION = "libs"
LICENSE = "GPLv2+ & LGPLv2.1+"
LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
                    file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
                    file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e"
DEPENDS = "udev libusb dbus-glib glib-2.0 libcheck readline"
PROVIDES += "bluez-hcidump"
RPROVIDES_${PN} += "bluez-hcidump"

RCONFLICTS_${PN} = "bluez4"

PACKAGECONFIG ??= "obex-profiles"
PACKAGECONFIG[obex-profiles] = "--enable-obex,--disable-obex,libical"
PACKAGECONFIG[experimental] = "--enable-experimental,--disable-experimental,"

SRC_URI = "\
    ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
    file://out-of-tree.patch \
    file://set_device_class.patch \
    file://init \
    file://run-ptest \
    ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '', 'file://0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch', d)} \
    file://0001-tests-add-a-target-for-building-tests-without-runnin.patch \
"
S = "${WORKDIR}/bluez-${PV}"

inherit autotools pkgconfig systemd update-rc.d distro_features_check ptest

EXTRA_OECONF = "\
  --enable-tools \
  --disable-cups \
  --enable-test \
  --enable-datafiles \
  ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '--enable-systemd', '--disable-systemd', d)} \
  --enable-library \
"

# bluez5 builds a large number of useful utilities but does not
# install them.  Specify which ones we want put into ${PN}-noinst-tools.
NOINST_TOOLS_READLINE ??= ""
NOINST_TOOLS_EXPERIMENTAL ??= ""
NOINST_TOOLS = " \
    ${NOINST_TOOLS_READLINE} \
    ${@bb.utils.contains('PACKAGECONFIG', 'experimental', '${NOINST_TOOLS_EXPERIMENTAL}', '', d)} \
"

do_install_append() {
    install -d ${D}${INIT_D_DIR}
    install -m 0755 ${WORKDIR}/init ${D}${INIT_D_DIR}/bluetooth

    install -d ${D}${sysconfdir}/bluetooth/
    if [ -f ${S}/profiles/audio/audio.conf ]; then
        install -m 0644 ${S}/profiles/audio/audio.conf ${D}/${sysconfdir}/bluetooth/
    fi
    if [ -f ${S}/profiles/network/network.conf ]; then
        install -m 0644 ${S}/profiles/network/network.conf ${D}/${sysconfdir}/bluetooth/
    fi
    if [ -f ${S}/profiles/input/input.conf ]; then
        install -m 0644 ${S}/profiles/input/input.conf ${D}/${sysconfdir}/bluetooth/
    fi

        if [ -f ${S}/src/main.conf ]; then
        install -m 0644 ${S}/src/main.conf ${D}/${sysconfdir}/bluetooth/
    fi

  if [ -f ${D}/${sysconfdir}/init.d/bluetooth ]; then
    sed -i -e 's#@LIBEXECDIR@#${libexecdir}#g' ${D}/${sysconfdir}/init.d/bluetooth
  fi

    # Install desired tools that upstream leaves in build area
        for f in ${NOINST_TOOLS} ; do
        install -m 755 ${B}/$f ${D}/${bindir}
    done
}

ALLOW_EMPTY_libasound-module-bluez = "1"
PACKAGES =+ "libasound-module-bluez ${PN}-testtools ${PN}-obex ${PN}-noinst-tools"

FILES_libasound-module-bluez = "${libdir}/alsa-lib/lib*.so ${datadir}/alsa"
FILES_${PN} += "${libdir}/bluetooth/plugins/*.so ${base_libdir}/udev/ ${nonarch_base_libdir}/udev/ ${systemd_unitdir}/ ${datadir}/dbus-1"
FILES_${PN}-dev += "\
  ${libdir}/bluetooth/plugins/*.la \
  ${libdir}/alsa-lib/*.la \
"

FILES_${PN}-obex = "${libexecdir}/bluetooth/obexd \
                    ${exec_prefix}/lib/systemd/user/obex.service \
                    ${datadir}/dbus-1/services/org.bluez.obex.service \
                   "
SYSTEMD_SERVICE_${PN}-obex = "obex.service"

FILES_${PN}-testtools = "${libdir}/bluez/test/*"

def get_noinst_tools_paths (d, bb, tools):
    s = list()
    bindir = d.getVar("bindir", True)
    for bdp in tools.split():
        f = os.path.basename(bdp)
        s.append("%s/%s" % (bindir, f))
    return "\n".join(s)

FILES_${PN}-noinst-tools = "${@get_noinst_tools_paths(d, bb, d.getVar('NOINST_TOOLS', True))}"

RDEPENDS_${PN}-testtools += "python python-dbus python-pygobject"

SYSTEMD_SERVICE_${PN} = "bluetooth.service"
INITSCRIPT_PACKAGES = "${PN}"
INITSCRIPT_NAME_${PN} = "bluetooth"

EXCLUDE_FROM_WORLD = "1"

do_compile_ptest() {
        oe_runmake buildtests
}

do_install_ptest() {
        cp -r ${B}/unit/ ${D}${PTEST_PATH}
        rm -f ${D}${PTEST_PATH}/unit/*.o
}

1.SUMMARY

用于打包系统（例如opkg，rpm或dpkg）的二进制包的（72个字符或更少）摘要。 默认情况下，如果在配方中未设置DESCRIPTION，则使用SUMMARY的值定义DESCRIPTION变量。

2.DESCRIPTION

提供给包管理器的包描述信息。如果未设置，DESCRIPTION将使用SUMMARY变量的值。

3.HOMEPAGE

一般为配方的正在构建的软件的主页,从中可以获取更多的软件信息。

4.SECTION

用于对软件包进行分类，此变量用于软件包管理程序。

5.LICENSE

配方的源文件LICENSE列表。LICENSE需遵循以下规则：
　　（1）不要在单个LICENSE名称中使用空格。
　　（2）当LICENSE可选择多个时，使用 | 分隔LICENSE。
　　（3）当存在涵盖源文件的不同部分的多个LICENSE时，使用 ＆ 分隔LICENSE。
　　（4）您可以在LICENSE名称之间使用空格。
　　（5）对于标准LICENSE，请使用meta / files / common-licenses /中的LICENSE，或者在meta / conf / licenses.conf中定义的具有SPDXLICENSEMAP标志的LICENSE。
下面是一些例子：

 LICENSE =“LGPLv2.1 | GPLv3”
 LICENSE =“MPL-1＆LGPLv2.1”
 LICENSE =“GPLv2 +”

第一个示例来自Qt的配方，源文件可以选择LGPLv2.1或GPLv3许可。第二个示例来自Cairo，其中两个 LICENSE涵盖源代码的不同部分。最后一个示例来自sysstat，它提供了一个单一的 LICENSE。
您还可以针对每个包指定 LICENSE以处理输出组件具有不同的LICENSE情况。例如，如果某个软件的代码根据GPLv2许可，但是文档却根据GNU 1.2自由文档许可，其LICENSE可以被规定如下：

LICENSE =“GFDL-1.2＆GPLv2”
LICENSE _ $ {PN} =“GPLv2”
LICENSE _ $ {PN} -doc =“GFDL-1.2”

6.LIC_FILES_CHKSUM

配方文件构建的软件源代码中的LICENSE文本的校验和。
此变量跟踪软件源代码文件的LICENSE文本的更改。如果LICENSE文本被更改，它将触发构建失败，这使开发人员有机会审查任何LICENSE更改。
所有配方文件必须定义此变量（除非LICENSE设置为“CLOSED”）。

7.DEPENDS

列出配方的构建时的依赖项（即其他配方文件）。在执行配方的配置任务之前，系统确保列出的所有依赖项都已构建，并且所有依赖项的内容已经保存在相应的sysroot中。
考虑这个简单的例子，两个名为“a”和“b”的配方生成类似命名的包。 在本示例中，DEPENDS语句出现在“a”配方中：

DEPENDS =“b”  

这里，DEPENDS 使得配方“a”的do_configure任务取决于配方“b”的do_populate_sysroot任务。 这意味着当配方“a”正在配置自身时，配方“b”放入sysroot的任何内容都必须可用。

8.PROVIDES

用于提供配方的别名。 默认情况下，配方自己的PN已经包含在PROVIDES列表中。如果配方使用PROVIDES，则别名是配方的PN的同义词，并可被用于其他配方的DEPENDS中。
以配方文件libav_0.8.11.bb为例，libav_0.8.11.bb中的PROVIDES语句如下：

PROVIDES + =“libpostproc”

该PROVIDES语句使得“libav”配方也被称为“libpostproc”。

9.RPROVIDES

用于提供包名的别名列表。 这些别名用于满足其他包在在构建期间和指定目标时（在RDEPENDS所指定的）的运行时依赖。
注意
程序包自身的名称（PN）已隐含在其RPROVIDES列表中。
与所有程序包控制变量一样，您必须始终将该变量与包名结合使用。例如：

RPROVIDES _ $ {PN} =“widget-abi-2”

10.RCONFLICTS

用于指定与当前软件包冲突的软件包列表。请注意，如果没有先删除冲突的包，则不会安装当前软件包。
与所有包控制变量一样，您必须始终将其与包名结合使用。例如：

RCONFLICTS _ $ {PN} =“another_conflicting_package_name”

OpenEmbedded构建系统使用的BitBake支持指定冲突的软件包版本。虽然语法因软件打包格式而异，但BitBake会隐藏这些差异。 下面是使用RCONFLICTS变量指定冲突的软件包的一般语法：

RCONFLICTS _ $ {PN} =“package（operator version）”

对于operator，您可以指定以下内容：

 =
 <
 >
 <=
 >=

例如，以下内容说明了当前软件包与软件包foo的1.2或更高版本冲突：

RCONFLICTS _ $ {PN} =“foo（> = 1.2）”

11. PACKAGECONFIG

该变量提供了在配方上启用或禁用配方的feature的方法。您可以在配方中指定feature以及feature的参数来创建PACKAGECONFIG块。以下是基本的块结构：

PACKAGECONFIG ?? =“f1 f2 f3 ...”
PACKAGECONFIG [f1] =“--with-f1， - without-f1，build-deps-f1，rt-deps-f1”
PACKAGECONFIG [f2] =“--with-f2， - without-f2，build-deps-f2，rt-deps-f2”
PACKAGECONFIG [f3] =“--with-f3， - without-f3，build-deps-f3，rt-deps-f3”

PACKAGECONFIG首先指定了一个空格分隔的要启用的feature列表。在feature列表下面，您可以通过提供最多四个按顺序排列的参数来确定每个feature的行为，这些参数之间用逗号分隔。您可以省略任何您喜欢的参数，但必须保留逗号分隔符。您必须按照以下顺序指定feature的参数：
　　1.如果启用了该功能，则应将额外的参数添加到配置脚本参数列表 （EXTRA_OECONF）。
　　2.如果禁用了该功能，应该将额外的参数添加到EXTRA_OECONF。
　　3.如果启用了该功能，则应添加附加的构建时依赖关系（DEPENDS）。
　　4.如果启用了该功能，应该添加附加的运行时依赖关系（RDEPENDS）。
以librsvg中的PACKAGECONFIG块为例。在这个例子中，feature是croco，它通过三个参数来确定其行为。

PACKAGECONFIG ?? =“croco”
PACKAGECONFIG [croco] =“ - with-croco，- without-croco，libcroco”

–with-croco和libcroco参数仅在启用此feature时适用。在这种情况下，–with-croco将被添加到配置脚本的参数列表中，而libcroco将被添加到DEPENDS中。另一方面，如果您通过另一层中的.bbappend文件禁用该功能，则第二个参数–without-croco将会被添加到配置脚本中，而不是–with-croco。基本的PACKAGECONFIG结构适用于创建块或者更改块。如果要更改现有的PACKAGECONFIG块，可以采用以下两种方法之一：
　　1.附加文件：在您的层（layer）中创建一个名为recipename.bbappend的附加文件，并覆盖PACKAGECONFIG的值。您可以完全覆盖变量的值：

PACKAGECONFIG =“f4 f5”

　　或者，您可以只添加变量的值：

PACKAGECONFIG_append =“f4”

　　2.配置文件：如果您没有修改local.conf或mydistro.conf文件，此方法与通过附加文件更改块相同。与之前描述的附加文件一样，您可以完全覆盖变量的值：

PACKAGECONFIG_pn-recipename =“f4 f5”

　　或者，您可以只修改变量的值：

PACKAGECONFIG_append_pn-recipename =“f4”

12.SRC_URI

用于指定源文件列表（本地或远程）。这个变量告诉OpenEmbedded构建系统哪些位要进入构建以及如何获取它们。例如，如果配方或附加文件只需要从Internet中提取压缩后的源文件，则配方或附加文件只需使用单个SRC_URI条目即可。另一方面，如果配方或附加文件需要同时获取压缩后的源文件，应用两个补丁以及自定义文件，则配方或附加文件中的SRC_URI变量将包括四个条目。
以下列出了可用的URI协议：
　　file：//-从本地获取文件，这些文件通常是元数据附带的文件。其路径相对于FILESPATH变量。因此，构建系统按顺序从配方文件（.bb）或附加文件（.bbappend）所在的目录的子目录中搜索：

$ {BPN} - 没有任何特殊后缀或版本号的配方名称。
$ {BP} - $ {BPN} - $ {PV}。配方的名称和版本，但没有任何特殊的包名称后缀。

files - files目录中的文件，一般配方或附加文件旁边。
　　注意：
　　如果希望构建系统从append文件中选取通过SRC_URI语句指定的文件，则可以通过在append文件中使用FILESEXTRAPATHS变量来扩展FILESPATH变量。
　　bzr：// - 从Bazaar版本控制存储库获取文件。
　　git：// - 从Git版本控制存储库获取文件。
　　osc：// - 从OSC（OpenSUSE Build服务）版本控制存储库获取文件。
　　repo：// - 从repo（Git）存储库获取文件。
　　ccrc：// - 从ClearCase存储库获取文件。
　　http：// - 使用http从Internet获取文件。
　　https：// - 使用https从Internet获取文件。
　　ftp：// - 使用ftp从Internet获取文件。
　　cvs：// - 从CVS版本控制存储库获取文件。
　　hg：// - 从Mercurial（hg）版本控制存储库获取文件。
　　p4：// - 从Perforce（p4）版本控制存储库获取文件。
　　ssh：// - 从安全shell获取文件。
　　svn：// - 从Subversion（svn）版本控制存储库获取文件。
针对SRC_URI的每个条目还有一些标准和特定的配方选项。以下是标准选项：
　　apply - 是否应用补丁。默认操作是应用补丁。
　　striplevel - 应用补丁时使用的级别。默认级别为1。
　　patchdir - 指定补丁的目录。默认值为$ {S}。
以下是版本控制系统针对配方构建代码的选项：
　　mindate - 只有在SRCDATE等于或大于mindat时才应用补丁
　　maxdate - 仅当SRCDATE不晚于mindate时才应用补丁。
　　minrev - 仅当SRCREV等于或大于minrev时才应用补丁。
　　maxrev - 仅当SRCREV不晚于maxrev时才应用补丁。
　　rev - 仅当SRCREV等于rev时才应用补丁。
　　notrev - 仅当SRCREV不等于rev时才应用补丁。
这里还有一些值得一提的额外选项：
　　unpack - 控制是否解压缩文件（如果是归档文件）。默认操作是解压缩文件。
　　subdir - 将文件（或提取其内容）放置到WORKDIR的指定子目录中。此选项对于异常tarball或其他那些解压后文件不放置在子目录的归档文件非常有用。
　　name - 当SRC_URI中有多个文件时，指定与SRC_URI校验相关的名称。
　　downloadfilename - 指定存储下载文件时使用的文件名。

13.inherit

用于指定在解析过程中应继承的类。 该变量仅在配置文件中有效。

14.EXTRA_OECONF

指定用于configure 的参数。

15.S

配方文件中源文件解压缩后在build目录中的位置。 此位置在工作目录（WORKDIR）中，且不是静态的。 解压缩后的源文件位置取决于配方名称（PN）和配方版本（PV），如下所示：

$ {WORKDIR} / $ {PN} - $ {PV}

例如，假设一个名为poky的源目录顶级文件夹和一个poky / build的默认构建目录。 在这种情况下，构建系统用于保留db配方源文件解压缩后的目录如下：
poky / build / tmp / work / qemux86-poky-linux / db / 5.1.19-r3 / db-5.1.19

16.D

目标目录。do_install任务在build目录中安装组件的位置。 此位置默认为：

$ {WORKDIR} / image

17.WORKDIR

OpenEmbedded构建系统构建配方的工作目录的路径名。此目录位于TMPDIR目录结构中，并且特定于正在构建的配方和正在构建的系统。
WORKDIR目录定义如下：

$ {TMPDIR} / work / $ {MULTIMACH_TARGET_SYS} / $ {PN} / $ {EXTENDPE} $ {PV} - $ {PR}

实际目录取决于几个事情：
　　TMPDIR：最上层构建输出目录
　　MULTIMACH_TARGET_SYS：目标系统
　　PN：配方名称
　　EXTENDPE：时间戳？ - （如果PE未指定，这通常是大多数配方的情况，则EXTENDPE为空）
　　PV：配方版本
　　PR：配方修订版
例如，假设源目录最上层文件夹名称为poky，默认构建目录为poky/build，目标系统为qemux86-poky-linux。此外，假设您的配方名为foo_1.3.0-r0.bb。在这种情况下，构建系统用于构建包的工作目录（WORKDIR）将如下所示：
poky / build / tmp / work / qemux86-poky-linux / foo / 1.3.0-r0

18.ALLOW_EMPTY

如果输出包为空，仍然应该生成包。 默认情况下，BitBake不产生空包。当存在RDEPENDS或某些其他硬件运行时的需要时，此默认行为可能会导致问题。
与所有程序包控制变量一样，您必须始终将其与包名(PN)结合使用，如：

ALLOW_EMPTY _ $ {PN} =“1”
ALLOW_EMPTY _ $ {PN} -dev =“1”
ALLOW_EMPTY _ $ {PN} -staticdev =“1”

19.PACKAGES

配方创建的包的列表。 默认值如下：

$ {PN} -dbg $ {PN} -staticdev $ {PN} -dev $ {PN} -doc $ {PN} -locale $ {PACKAGE_BEFORE_PN} $ {PN}

20.FILES

指定需要放入包中的目录或文件的列表。
使用FILES变量时，必须与生成包的包名结合使用。然后提供一个空格分隔的文件或路径列表，用于标识要包含在生成包中的文件。例如：

FILES _ $ {PN} + =“$ {bindir} / mydir1 / $ {bindir} / mydir2 / myfile”

注意:
当为FILES变量指定文件或路径时，最好使用相对路径。例如，使用 sysconfdir而不是/etc，或 {bindir}而不是/ usr / bin。您可以在源目录中的meta / conf / bitbake.conf文件的顶部找到这些变量的列表。
如果您提供的FILES变量中的一些文件是可编辑的，并且您知道它们不应该在软件包管理系统（PMS）的软件包更新过程中被覆盖，您可以让PMS识别这些文件，以便PMS不会覆盖它们。有关如何使PMS的识别这些文件，请参考CONFFILES变量。

21.SYSTEMD_SERVICE

如果配方继承了systemd类，那么此变量为配方生成包的指定了systemd的服务名称。当您在配方中使用此文件时，请指定包名，以保证变量值应用到目标包上。下面是一个来自connman配方中的例子：

SYSTEMD_SERVICE _ $ {PN} =“connman.service”

22.RDEPENDS

列出包的运行时依赖关系（即其他程序包），依赖包必须先安装才能使当前构建的程序包正常运行。如果在构建过程中找不到此列表中的依赖包，构建将会失败。
当在配方中使用RDEPENDS变量时，说明当前配方的do_build任务取决于特定包。下面以两个名为“a”和“b”的配方为例，它们生成类似命名的IPK包。在此示例中，RDEPENDS语句显示在“a”配方中：

RDEPENDS _ $ {PN} =“b”

这里，RDEPENDS使得配方“a”的do_build任务取决于配方“b”的do_package_write_ipk任务。这意味着当构建配方“a”时，“b”的包文件必须可用。更重要的是，以包管理器理解的方式，包“a”将被标记为依赖于包“b。
在RDEPENDS中列出的包的名称必须是其他包的名称 - 它们不能是配方名称。虽然软件包名称和配方名称通常匹配，但重要的是，您必须在RDEPENDS变量中提供软件包名称。有关如何从配方创建软件包的示例，请参考PACKAGES变量。
因为RDEPENDS变量适用于正在构建的包，所以您应该始终使用带有附加的包名称的形式的变量名。例如，假设您正在构建一个依赖于perl包的开发包。在这种情况下，您将使用以下RDEPENDS语句：

RDEPENDS _ $ {PN} -dev + =“perl”

在该示例中，RDEPENDS变量具有$ {PN} -dev包名称作为变量名的一部分。
附加到RDEPENDS变量的程序包，在通过类（如debian）重命名之前，其包名必需同PACKAGES命名空间中的名称一致。
在许多情况下，您不需要使用RDEPENDS显式添加运行时的依赖包，因为配方会自动运行某些处理：
shlibdeps：如果运行时的程序包包含共享库（.so），构建过程中将处理库以及与其动态链接的其他库，并在创建运行时的包时将这些库添加到RDEPENDS。
pcdeps：如果程序包含有pkg-config文件，则构建过程中将使用此文件将条目添加到RDEPENDS变量以创建运行时的程序包。
OpenEmbedded构建系统使用的BitBake支持依赖指定版本的特性。虽然语法因软件包打包格式而异，但BitBake会隐藏这些差异。以下是使用RDEPENDS变量指定依赖软件包版本的一般语法：

RDEPENDS _ $ {PN} =“package（operator version）”

对于operator，您可以指定以下内容：

  =
  <
  >
  <=
  >=

例如，以下内容说明配方运行时依赖软件包foo的1.2或更高版本：

RDEPENDS _ $ {PN} =“foo（> = 1.2）”

有关构建时依赖的内容，请参考DEPENDS变量。

23.INITSCRIPT_PACKAGES

包含初始化的软件包列表。 如果有多个包，则应该使用带有附加的包名称的形式的变量名。
只有配方继承update-rc.d.bbclass，此变量才可使用。该变量是可选的且默认为值为PN。

24.INITSCRIPT_NAME

安装到$ {sysconfdir} /init.d的初始化脚本名。
只有配方继承update-rc.d.bbclass，此变量才可使用。 此变量是必需的。

25.EXCLUDE_FROM_WORLD

将当前配方从BitBake world 中排除。 在执行BitBake world期间，BitBake会定位，解析和构建在bblayers.conf配置文件中公开的每一层的配方。
如果需要BitBake world不构建当前配方，请在配方中将EXCLUDE_FROM_WORLD变量设置为“1”。
注意:
如果有其他配方依赖于设置EXCLUDE_FROM_WORLD的值为1的配方，则此配方仍然可能被BitBake world构建。 将EXCLUDE_FROM_WORLD设置为1,仅确保配方未显式添加到BitBake world的构建目标列表中。

Bitbake工作流：

自定义配方

关于如何新建配方，可以查看：http://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe