Workflow of Bitbake

1. Source Fetching

第一步要构建一个recipe ，其首先通过do_fetch和do_unpack 两个任务指令去下载并提取sourcecode内容，并将内容放置工作目录当中。

Note

默认情况下，所有完成的项目都会在build目录下（build目录根据不同的数据关系定义了相应的数据存储目录结构）。

变量S 决定了unpack得到的sourcecode所指向的位置。每一个recipe在build目录都有属于自己的存储空间用来存放unpack得到的sourcecode。

"              TMPDIR-所有在OpenEmbedded系统中的工作，都会在此目录下完成build过程。

"              PACKAGE_ARCH- Build 单个或者多个package时的结构。

"              TARGET_OS- 目标设备的操作系统。

"              PN-被Build的package名称。

"              PV-用来buildpackage的recipe 版本。

"              PR- Build package的recipe的修订版。

"              WORKDIR-在TMPDIR目录下，build某个明确指定的package时的工作目录。

"              S-包含了某个recipe所指定的相关unpack后的源文件。

2. Patching

一旦source code被下载解压提取之后，bitbake将定位到patch文件的位置，并且将patch添加到源文件中。

执行do_patch的任务过程中，通过SRC_URI变量来定位将要使用的patch文件，默认情况下是*.patch或者*.diff 文件，或者使用"apply=yes"来明确指定是否添加当前在SRC_URI中的patch。例：

SRC_URI ="${GNU_MIRROR}/bash/${BPN}-${PV}.tar.gz;name=tarball \

          ${GNU_MIRROR}/bash/bash-4.3-patches/bash43-001;apply=yes;striplevel=0;name=patch001\

          ${GNU_MIRROR}/bash/bash-4.3-patches/bash43-002;apply=yes;striplevel=0;name=patch002\

                 "

Bitbake 为一个recipe查找并添加多个patch，其添加顺序为按找到patch的时间顺序。patch将被添加到在S 目录结构下的recipe源文件。

 

3.Configuration and Compilation

这一步在build过程中包括三个任务：

 

任务主要用来配置被build软件的配置选项以及build时间（打开或者关闭），配置内容可以来自自身的recipe文件，也可以继承class中规定的配置，另外，软件本身的配置参数可能依赖于它自己build目标。

由do_configure 处理recipe指定的sourcecode配置参数。

还可以使用autotools class来添加额外的配置参数，使用EXTRA_OECONF或PACKAGECONFIG_CONFARGS变量。可以通过meta/classes/autotools.bbclass来查看这些变量是如何运作的。

一旦完成配置，bitbake用do_compile来编译compile 源数据。编译的目录是由B变量所指定的位置决定。并且我们应当知道，B目录在默认情况下与S目录相同。

当编译完成后，bitbake执行do_install，这个过程是拷贝B目录下的文件到变量D所指定的holding区域。

4. Package Splitting

当sourcecode配置编译完成后，OE（OpenEmbeded）build系统将分析结果，并将其分割成不同的packages。

 do_package和do_packagedata俩个任务结合在一起用于分析D目录下的文件，再根据可获取的package和文件，将他们分割成的不同子模块。分析过程包括：1.撇去debug特征符，2.查找多个package间的共享库，3.查找不同package直接的关系。do_packagedata任务创建满足OE最终生成package所需的元数据metadata。

"              PKGD-在packages被分前所有package的存放目录。

"              PKGDATA_DIR-一个共享的全局状态目录，其存放了packaging过程中产生的数据。

"              PKGDESTWORK-被do_package所调用的一个零时工作区。

"              PKGDEST- Package被分派之后的父目录。

FILES定义了要存放入不同PACKAGES对应的不同文件。

根据不同类型的package，do_package_write_*用于创建实际的package并将其放到packageFeed位置${TMPDIR}/deploy。

5. Image Generation

当所有package被分派并存放到packagefeed区域后，OE将会用bitbake来构建root文件系统镜像。

Image的产生过程包含多个不同的步骤，并且依赖于不同的任务tasks和变量。do_rootfs任务用于创建一个image的root文件系统（文件&目录结构），这个任务用到几个关键变量来帮助创建一些最后将会安装的package。

"              IMAGE_INSTALL:从Feedarea中，列出了一组将被安装的基本packages

"              PACKAGE_EXCLUDE:明确指定哪些package不被安装

"              IMAGE_FEATURES:指定一些image的特性，这些特性大都与额外安装的package相匹配。

"              PACKAGE_CLASSES:明确package的后台特性，以此使得可以更方便的在Feed区找到该package。

"              IMAGE_LINGUAS:决定语言安装包。

"              PACKAGE_INSTALL:最后的一些将被安装入image的package列表（通过packagemanager）。

 

通过IMAGE_ROOTFS指向构建文件系统的位置，以及通过变量PACKAGE_INSTALL提供最后将要安装的packages，文件系统由此创建。

Package 的安装是通过package manager来管理，而不是由packagemanagement 中的设置决定。在最后的过程，当package management中未enablepackage， 那么未enable的目标package将会从filesystem中删除。最后存放在stage上的安装脚本以及安装后的配置脚本scripts作为package的一部分来运行。所有的脚本在targetsystem 目标系统上运行的脚本，都不能在build系统上运行。如果在只读的根文件系统上运行脚本，那么所有脚本都必须在package的安装过程中成功的安装入package里面。

最后步骤，do_rootfs 任务主要处理后续过程，包括创建manifest文件以及优化。

Manifest文件（.manifest）存放在与image镜像文件系统rootfilesystem相同的路径下。manifest 文件对testimage的类很有用，例如，是否执行某个测试案例。

优化的过程使用的一些指令由ROOTFS_POSTPROCESS_COMMAND指定包括mklibs,prelink等

当文件系统创建以后，build image镜像的进程从执行do_image的任务开始。编译系统想进行任何预处理指令，都在IMAGE_PREPROCESS_COMMAND变量中指定。这个变量指明了在最终image输出文件产生前的将调用的函数。

 

do_image 任务按需动态创建其他的do_image*任务，其中包括压缩root文件系统的镜像（减小image过大的占用空间）。这个过程将所有的东西转化成一个或者多个image文件。root文件系统的格式由IMAGE_FSTYPES指定。

Image创建的最后一个任务是do_image_complete 。一旦OE编译系统创建玩最后的外部输出文件，这个任务将调用定义在IMAGE_POSTPROCESS_COMMAND变量中的后续处理函数。

Note

The entire image generation process is rununder Pseudo. Running under Pseudo ensures that the files in the rootfilesystem have correct ownership.