OE中的bitbake使用

OpenEmbedded是一些脚本（shell和python脚本）和数据构成的自动构建系统。
脚本实现构建过程，包括下载（fetch）、解包（unpack）、打补丁（patch）、configure、编译（compile）、安装（install）、打包（package）、staging、做安装包（package_write_ipk）、构建文件系统等。
1、OE编译顺序：

do_setscene
do_fetch
do_unpack
do_patch
do_configure
do_qa_configure
do_compile
do_stage
do_install
do_package
do_populate_staging
do_package_write_deb
do_package_write
do_distribute_sources
do_qa_staging
do_build
do_rebuild

2、每个do都可以添加_append，_prepare操作：

do_configure_prepend ()
do_compile_prepend ()
python do_compile_prepend ()
do_stage_prepend()
do_install_prepend()
do_package_prepend()
python populate_packages_prepend ()

带有python的函数，其函数内容是使用python定义的，否则使用shell 语法定义。
do_compile这些函数都是在openembedded的classes中定义的，在bitbake中没有对这些进行定义。这说明，bitbake只是oe更底层的一个工具，oe是基于bitbake架构来完成的。

文件系统里的OpenEmbedded
OE环境中最重要的目录有3个：放工具的bitbake目录、放元数据的目录、和执行构建的build目录。
bitbake目录
这个目录里是我们的烹饪工具：bitbake。我们使用它，但通常不需要访问它
元数据目录
在poky中元数据目录是meta。Openmoko中元数据目录是openembedded。在元数据目录中，有3个目录里是真正的元数据。它们是：classes、conf和packages。
packages目录
所有的配方(recipes)文件（以.bb为后缀名）都放在package目录。每个相对独立的软件包或构建任务在package目录下都有自己的子目录。在一个子目录中可以有多个配方(recipes)文件。它们可能是同一个软件包的不同版本。也可能描述了基于同一个软件包的不同构建目标。
有的配方(recipes)简单,有的配方(recipes)复杂。简单的配方(recipes)仅描述一个软件包的构建。最复杂的配方(recipes)就是要求构建文件系统的配方(recipes)，这个配方(recipes)文件本身并不长，甚至还很短，但它通过依赖关系将几百个甚至几千个其它配方(recipes)件卷入了构建过程。 packages目录的images子目录下就是这些要求构建文件系统的配方(recipes)。
classes目录
这个目录放的是配方(recipes)的类文件（以.bbclass为后缀名）。类文件包含了一些bitbake任务的定义，例如怎么配置、怎么安装。配方(recipes)文件继承类文件，就继承了这些任务的定义。例如：我们如果增加一个使用autotool的软件包，只要在配方(recipes)文件中继承autotools.bbclass：
inherit autotools
bitbake就知道怎样使用autotool工具配置、编译、安装了。所有的配方(recipes)文件都自动继承了base.bbclass。 base.bbclass提供了大部分bitbake任务的默认实现。
一个配方(recipes)文件可以继承多个类文件。以后的文章会介绍bitbake的任务，届时会更详细地讨论bitbake的继承。目前，我们只要知道继承类文件是一种构建过程的复用方式就可以了。
conf目录
conf目录包含编译系统的配置文件（以.conf为后缀名）。bitbake在启动时会执行bitbake.conf。
bitbake.conf会装载用户提供的local.conf。然后根据用户在local.conf中定义的硬件平台（MACHINE）和发布目标（DISTRO）装载machine子目录和distro子目录的配置文件。machine子目录里是硬件平台相关的配置文件。distro子目录里是与发布目标相关的配置文件。配置文件负责设置bitbake内部使用的环境变量。这些变量会影响整个构建过程
build目录
build是我们烹饪嵌入式系统的大厨房。整个构建过程就是在build目录的tmp子目录完成的。 build目录的conf子目录里是用户的配置文件local.conf。
tmp目录有7个子目录：cache、cross、rootfs、staging、work、deploy和stamps目录。其中cache是bitbake内部使用的缓存目录。cross是构建过程中产生的交互编译器。所谓交互编译器就是在主机平台运行，用于编译目标平台代码的编译器。 rootfs是制作文件系统映像前临时建立的根文件系统。我们在工作中通常不需要访问这3个目录。我们访问比较多的是其它4个目录：staging、work、deploy和stamps目录。
1. staging目录
软件包B在构建时可能依赖软件包A提供的头文件、库文件，也可能要使用软件包C生成的工具。 staging目录就是放这些输出文件的地方。
我们必须在配方(recipes)文件中用“DEPENDS”变量声明构建时的依赖关系。bitbake就会在构建软件包B前先构建软件包A和软件包C，并将软件包B需要的头文件、库文件、和工具放在staging目录。这样，在构建软件包， 时就可以从staging目录得到需要的头文件、库文件、和工具。
2. work目录
所有软件包的解包、打补丁、配置、编译、安装等工作都是在work目录进行的。所以work目录包含了整个嵌入式系统的完整源代码。
work目录下按照硬件平台、发行人、目标平台的不同又分了几个子目录。所有软件包都被放在对应子目录中。每个软件包都有一个独立的目录。因为软件包总是 根据一个配方(recipes)文件构建的，所以软件包所在的目录就是对应配方(recipes)文件的工作目录。在讨论bitbake和配方(recipes)文件时我们还会回来，更仔细地观察配方(recipes)文件的工作
3 deploy目录
这是保存输出成果的目录。其中images目录保存构建成功后产生的文件系统映像、内核映像。 ipk目录保存每个软件包的安装包。我们在修改、构建软件包后，可以在目标平台手工安装ipk目录下的对应安装包。确认没有问题后，再制作文件系统映像。
4 stamps目录
和work目录类似，stamps目录也按照硬件平台、发行人、目标平台的不同又分了几个子目录。软件包在完成每个bitbake任务后都会在对应子目录里touch一个对应任务的时间戳。有时我们会手工删除某个软件包的时间戳，强制bitbake重新构建这个软件包。
5 sources目录
OE环境的sources目录是一个储藏间，用来放从网上下载的源代码包。 fetch任务负责下载代码，放到sources目录。

---

OE的主要功能是为各种工程项目的需要编译源码。不管是什么工程，以下任务都是要作的：
1. 下载源码包，还有其他的系统支持文件（比如初始化脚本）；
2. 解压源码包，然后打上需要的补丁；
3. 如果需要的话就进行软件包配置（比如运行configure脚本）；
4. 编译所有的东西；
5. 把所有编译好的文件打成各种格式的包，然后准备安装。

其实这些并没有什么非常不寻常的。困难的是：
1. 交叉编译：交叉编译是困难的，大部分软件包根本不支持交叉编译，OE里包含的都是支持交叉
编译的。
2. 目标系统和主机是不同的： 这意味着你不能编译一个程序就直接运行它—那是给在目标板上
运行的。有很多的软件包在编译的时候会编译并且运行一些帮助或者测试程序，这在交叉编译的时
候会导致失败。
3.工具链总是很难编译的。交叉工具链更是如此。通常情况下你可能会选择去下载一个别人做好的，
但是使用OE你就不需要如此。在OE里整个工具链在编译系统的时候都会被创建。OE的这种方式或许
在开始的时候会带来一些困难和不便。但是如果你需要打上补丁或者对工具链做些调整就会很容易。

当然，除了这些之外，oe还有很多的功能，其中包括：
* 同时支持glibc和uclibc;
* 只使用oe一个工具你就可以为多种目标机器构建系统；
* 自动编译一切构建时和编译时依赖的包；
* 直接创建各种可以在目标机器上直接运行的镜像(包括jffs2,ext2.gz,squashfs等等)；
* 支持各种打包格式；
* 自动构建交叉工具链；
* 支持构建“本地包”。本地包指为了完成编译给主机编译的包，最终不会用到目标板上。
本章以下内容假设你已经掌握了OE的Getting Start guides（新手指南）,并且已经能够正确安装和
配置oe，而且你也成功的构建了交叉工具链。

bitbake的常用命令：
bitbake -e 显示当前的执行环境，常用于查找当前bitbake的包的源路径和目标路径。
查找包的原路径 bitbake -e hello | grep ^SRC_URI
查找包的安装路径 bitbake -e hello | grep ^S=
bitbake -s 用于显示所有可以bitbake的包
例如如果自己在一个Layer下面安装了一个hello.bb,在build目录下面用 bitbake -s | grep hello 查看hello这个package能否被bitbake.
bitbake -c 用于执行一个特定的命令
bitbake -g 用于显示一个包在bitbake的时候于其他包的依赖关系
bitbake -v 显示执行过程。
bitbake -b 后面加上.bb文件的路径，可以用bitbake直接执行这个.bb文件。