DEPENDS += " A"
CFLAGS += " -I${WORKDIR}/recipe-sysroot/usr/include/api"
这样B模块就可以使用A模块编译的动态库。
该大阶段涉及但未解释的变量有以下：
包构建的编译目录，一般情况${B}与${S}相同，即为${WORKDIR}/${BPN}-${PV}。
包构建成果物的安装目录，也称为目标目录。默认情况这个目录为${WORKDIR}/image。
SYSROOT_DESTDIR
指向包构建工作目录下的临时目录，其默认值为${WORKDIR}/sysroot-destdir。
总结：源码配置、源码编译及成果物安装阶段就是引用依赖（如果有）完成源码配置、编译及成果物安装，安装的成果物可能是目标设备使用的，也可能是其他模块所需依赖。
在配置、编译和安装完成后，构建系统分析结果并将包拆分处理，比如将文件stripped后放入packages-split目录：
该阶段分为三个任务，分别为do_package、do_packagedata、do_populate_sysroot。
do_package、do_packagedata任务
do_package和do_packagedata任务组合起来分析在${D}目录中找到的文件，并根据可用的包和文件将它们分成子集。分析处理过程包括以下内容：去除调试符号，查看包之间的共享库依赖关系，以及查看包之间的关系。
do_packagedata任务根据分析创建包元数据放置Package Feeds（即PKGDATA_DIR指定目录）中，这样构建系统就可以从拿到包生成最终的image。
do_populate_sysroot任务
do_populate_sysroot任务在之前已经介绍过。该任务将自动拷贝${D}目录下部分子目录到${SYSROOT_DESTDIR}，并将${SYSROOT_DESTDIR}目录内容暂存至共享区（默认为build/tmp/sysroots-components）。自动拷贝的子目录由三个变量指定，分别为SYSROOT_DIRS（目标设备需要保存的子目录）、 SYSROOT_DIRS_BLACKLIST（目标设备不需要保存的子目录）、SYSROOT_DIRS_NATIVE（本机设备需要保存的目录），前面已经简要介绍过它们，详情请点入进官网参看。
该大阶段会涉及到以下变量：
PACKAGE_CLASSES
用于指定构建系统在打包文件时使用何种包管理器，该变量位于编译目标层的conf/local.conf.sample文件中（如有需要可在此文件中修改），这个文件将被解析到build/conf/local.conf文件中，比如设置其值为PACKAGE_CLASSES ?= "package_rpm package_tar"。
在将包拆分为单独的包之前，包的目标目录。
PKGDESTWORK
do_package任务用来保存包元数据的临时工作区(即pkgdata)。
PKGDEST
拆分后的包的父目录(即packages-split)。
PKGDATA_DIR
一个共享的全局状态目录，其中包含打包过程中生成的打包元数据。打包过程将元数据从PKGDESTWORK复制到PKGDATA_DIR区域，在那里元数据成为全局可用的。
STAGING_DIR_HOST
要运行组件的系统的系统根路径(即recipe-sysroot)，也就是当前配方源码编译时的根文件系统，里面包含配方所需依赖及交叉编译器所需依赖。
STAGING_DIR_NATIVE
为构建主机构建组件时使用的系统根路径(即recipe-sysroot-native)。
STAGING_DIR_TARGET
当构建在系统上执行的组件并为另一台机器生成代码（例如cross-canadian recipes）时使用的 sysroot 路径，一般与STAGING_DIR_HOST一样。
FILES
用于指定包（模块）安装在${D}目录中哪些成果物要打包，该变量位于配方文件中（如有需要可在此文件中修改）。简单来说就是在do_install任务中安装在${D}目录下的文件不会都打包，以rsa模块为例该变量的默认值为：
FILES_rsa="/usr/bin/* /usr/sbin/* /usr/libexec/* /usr/lib/lib*.so.* /etc /com /var /bin/* /sbin/* /lib/*.so.* /lib/udev /usr/lib/udev /lib/udev /usr/lib/udev /usr/share/hikrsa /usr/lib/hikrsa/* /usr/share/pixmaps /usr/share/applications /usr/share/idl /usr/share/omf /usr/share/sounds /usr/lib/bonobo/servers"
也就是说，只要成果物安装在上面这些目录下的都会参与打包，当然如果不放心或需要额外增加文件，可以在配方文件中显性指定：
FILES_${PN} += " \
${sbindir}/rsaverify \
" #${sbindir}默认为/usr/sbin/
总结：包拆分处理阶段就是根据conf配置将${D}目录中成果物打包放置于Package Feeds 区域，同时生成包元数据，最后将其他配方可能用到的文件放置于文件共享区（为其他配方提供依赖）。
注意，这个阶段在一般包（模块）编译过程中不存在！！！可通过bitbake -c listtasks XXX（包名或固件名）命令查看编译任务列表。
一旦软件包被拆分并存储在 Package Feeds 区域中，构建系统将使用 bitbake 生成根文件系统映像（image）：
该阶段涉及两个任务，分别为do_rootfs、do_image。
do_rootfs任务
该任务将创建目标设备的根文件系统（将需要打包至目标设备的程序、库、文件等都放置到根文件系统中），这个根文件系统最终打包到image中。do_rootfs任务会通过ROOTFS_POSTPROCESS_COMMAND来优化文件大小（如mklibs过程优化了库的大小，同时prelink优化了共享库的动态链接以减少可执行文件的启动时间），ROOTFS_POSTPROCESS_COMMAND如下：
ROOTFS_POSTPROCESS_COMMAND() {
write_package_manifest; license_create_manifest; ssh_allow_empty_password; ssh_allow_root_login; postinst_enable_logging;
rootfs_update_timestamp ; write_image_test_data ; set_systemd_default_target; systemd_create_users; empty_var_volatile;
remove_etc_version ; set_user_group; sort_passwd; rootfs_reproducible;
创建的文件系统所在位置由IMAGE_ROOTFS变量指定，查看示例：
~/work/bmc$ bitbake -e obmc-phosphor-image | grep ^IMAGE_ROOTFS
IMAGE_ROOTFS="~/work/bmc/build/tmp/work/4u_x201-openbmc-linux-gnueabi/obmc-phosphor-image/1.0-r0/rootfs"
如果我们修改了某个程序，但又不想重新烧写整个固件，那就去这个目录下找到程序，再通过TFTP方式（或NFS直接挂载）下载到目标是设备调试即可。
do_image任务
do_image 任务会通过 IMAGE_PREPROCESS_COMMAND 对image进行预处理，主要是优化image大小，IMAGE_PREPROCESS_COMMAND 如下：
IMAGE_PREPROCESS_COMMAND() {
mklibs_optimize_image; prelink_setup; prelink_image; reproducible_final_image_task;
构建系统do_image根据需要动态生成支持的 do_image_* 任务，生成的任务类型取决于IMAGE_FSTYPES变量。do_image_* 任务将所有内容转换为一个image文件或一组image文件，并且可以压缩根文件系统image大小，以减小最终烧写到目标设备的image整体大小。用于根文件系统的格式取决于 IMAGE_FSTYPES变量，压缩取决于格式是否支持压缩。
image生成完成后执行最后一个任务do_image_complete，该任务将通过IMAGE_POSTPROCESS_COMMAND完成image的后续处理，默认情况IMAGE_POSTPROCESS_COMMAND为空，查看示例：
~/work/bmc$ bitbake -e obmc-phosphor-image | grep ^IMAGE_POSTPROCESS_COMMAND
IMAGE_POSTPROCESS_COMMAND=""
该大阶段涉及变量如下：
IMAGE_INSTALL
该变量指明Package Feeds 区域安装的基本软件包集中，哪些包（模块）最终要打包到image，该变量一般位于编译目标层的conf/local.conf.sample文件中（如有需要可在此文件中修改），这个文件将被解析到build/conf/layer.conf文件中。注意与FILES差异，FILES是指明软件包内部哪些文件需要参与打包，而IMAGE_INSTALL是指明哪个软件包需要参与打包。
一个简单示例：
IMAGE_INSTALL_append += ”rsa"
PACKAGE_EXCLUDE
指定不应安装到image中的包。
IMAGE_FEATURES
指定要包含在图像中的特征，大多数这些功能映射到其他安装包（未能弄明白具体作用）。
IMAGE_LINGUAS
确定安装附加语言支持包的语言，该变量一般位于编译目标层的conf/local.conf.sample文件中（如有需要可在此文件中修改），这个文件将被解析到build/conf/layer.conf文件中。默认情况下为：
~/work/bmc$ bitbake -e rsa | grep ^IMAGE_LINGUAS
IMAGE_LINGUAS="en-us en-gb"
PACKAGE_INSTALL
传递给包管理器以安装到映像中的包的最终列表。
DEPLOY_DIR
最终image和SDK输出的目录，默认值为build/tmp/deploy/。
总结：image生成生成阶段就是创建目标设备的根文件系统，并将需要打包至目标设备的程序、库、文件等都放置到根文件系统中，然后对文件和整个文件系统进行优化压缩，最终生成image。
以api.bb的配方为例，其内容如下：
SUMMARY = "This is an example"
SECTION = "Examples"
HOMEPAGE = "http://www.xxx.com.cn/"
PR = "r1"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
FILESPATH := "${THISDIR}/../../sources/${PN}:"
DEPENDS += "audit"
DEPENDS += "phosphor-ipmi-host"
S = "${WORKDIR}"
SRC_URI += "\
file://Makefile \
file://make.libs \
file://api_common.h \
file://api_common.c \
file://api_ethernet.c \
file://api_ethernet.h \
SRC_URI += " \
file://api_systems.c \
file://api_systems.h \
FILESPATH_append := "${THISDIR}/../../../meta-common/sources/host-ipmid/ipmi/:"
SRC_URI_append = " \
file://sharememory.c \
TARGET_CC_ARCH += "${LDFLAGS}"
EXTRA_OEMAKE = " 'RECIPE_SYSROOT=${RECIPE_SYSROOT}' "
CFLAGS_prepend = "-I${WORKDIR}/recipe-sysroot/usr/include/audit "
do_install() {
oe_runmake DESTDIR=${D}${libdir} install
install -m 0644 -d ${D}${includedir}/api
install -m 0644 ${S}/api_common.h ${D}${includedir}/api
install -m 0644 ${S}/api_common.c ${D}${includedir}/api
install -m 0644 ${S}/api_ethernet.h ${D}${includedir}/api
install -m 0644 ${S}/api_systems.h ${D}${includedir}/api
下篇文章再见啦~~~~
本文参考yocto官方手册，如有理解不当之处，欢迎留言指出。项目概述和概念手册：https://docs.yoctoproject.org/overview-manual/index.html项目参考手册：https://docs.yoctoproject.org/ref-manual/index.htmlyocto项目的厨师——bitbake bitbake是OpenEmbedded构建系统的引擎，通过解析一系列配置文件（主要为recipes，即bb/bbappend文件）来创建任务列表，并根据
PiP2Bitbake
该Python脚本允许在最终的Yocto Project Linux映像中预安装任何Python pip （ PyPI ）（ Python软件包索引）-软件包。
为了使之成为可能，将生成带有所有必要信息（版本号，校验和..）的Bitbake文件，以允许Bitbake将所选的pip程序包包括到生成的Yocto-Project Linux发行版的rootfs中。
我开发了此Python脚本，以为英特尔SoC-FPGA创建嵌入式Linux。
Python脚本自动为Yocto Project创建Bitbake配方文件，以预安装任何Python pip软件包
几乎每个Python pip包都可以实现到自定义Linux发行版中当然，仅需要将该软件包作为跨平台版本提供即可
输出“ .bb” -Bitbake配方文件，该文件可以轻松包含到任何Yocto Project元
原文 http://blog.csdn.net/xiaofeng_yan/article/details/6757725
1 当你已经编完一个系统比如sato映像，在编一个meta-toolchain的映像如何重用已经下载的源码。
修改build/local.conf变量
DL_DIR=
2 如果你用ctl+c中断了编译过程，在重新编译的时候poky可能出现了一些问题。你个以这样做来避免...
首先将下载为~/bin/yocto-build
mkdir -p ~ /bin
curl https://raw.githubusercontent.com/coldnew/docker-yocto/master/yocto-build.sh > ~ /bin/yocto-build
chmod +x ~ /bin/yocto-build
将以下行添加到~/.bashrc文件中，以确保~/bin文件夹位于PATH变量中。
export PATH= ~ /bin: $PATH
第一次使用yocto-build命令时，您需要告诉它我们构建yocto映像的工作目录在哪里。
例如，如果我想在/
前部分文章讲解了Bitbake工作流程及yocto配方语法，但对于大部分未接触过yocto的朋友来说，还是难以理解的，正如yocto官方手册所说，yocto学习曲线无疑是十分陡峭。记得刚学编程时，就由编写运行一个“hello world!”程序入门，那么这篇文章同样由“hello world!”模块开启我们的学习之旅~~~
本文参考https://docs.yoctoproject.org/dev-manual/common-tasks.html#writing-a-new-recipe手册第3章节及htt
最近在使用zynq+ad9361，需要使用ADI提供的内核源码。按照UG1144的，Using External Kernel and U-Boot with PetaLinux。配置工程petalinux-config，在界面里配置linux components selection->linux-kernel->ext-local-src ，会弹出输入内核目录框，输入内核源码目录。
编译后，会出现do_compile: oe_runmake failed错误。然后查阅附近有关的错...
