OpenEmbedded 环境1

转自：http://blog.csdn.net/fmddlmyy/archive/2008/11/08/3254033.aspx

 

1、概述

OpenEmbedded（OE）是一个开源的嵌入式linux系统构建环境。Openmoko和poky都使用了定制过的OpenEmbedded环境。Openmoko是一个开放软硬件设计的手机平台。Poky的本意是一个定制过的OpenEmbedded环境。

Poky环境包含了一个叫作Sato的UI方案，我们有时也把这个方案叫作poky。其实我们可以在poky环境开发其它基于GTK+/Macthbox的UI方案。

构建一个嵌入式linux系统需要构建引导模块、内核和文件系统。这是一个相当复杂的过程，特别是文件系统的构建。一个典型的文件系统可能需要下载、编译、安装几百个软件包。如果你做过LFS（Linux FromScratch），就可以体会到手工创建文件系统的复杂性。嵌入式系统因为是交叉编译（在PC环境编译、在嵌入式环境运行），所以构建过程更加复杂。OpenEmbedded 就是为了简化嵌入式系统的构建过程而设计的。尽管存在着体积大、速度慢等缺点，但OpenEmbedded确实简化了嵌入式系统的构建过程。例如，在安装过需要的工具后，构建poky的完整过程只是在进入poky目录后，执行两条命令：

. poky-init-build-env

bitbake poky-image-sato

然后就是等待构建完成。构建过程可能需要12-36小时。目标系统的复杂程度、网速、软硬件环境都会影响构建时间。

在完成一次成功构建后，我们就可以在这个环境开发应用程序。这时我们只需要编译变化的部分。在应用开发完成后，我们可以手工将其安装到目标系统上测试。在需要的时候，也可以重新构建文件系统。这时，OE仅编译变化的软件包，并重做一次文件系统映像。重做一次文件系统映像大约需要10-15分钟。

2程序员看到的OpenEmbedded

2.1 脚本和数据

在程序员看来，OpenEmbedded是一些脚本（shell和python脚本）和数据构成的自动构建系统。脚本实现构建过程，包括下载（fetch）、解包（unpack）、打补丁（patch）、configure（如果使用了autotool）、编译（compile）、安装（install）、打包（package）、staging（以后讨论）、做安装包（package_write_ipk）、构建文件系统等。

数据主要提供两个方面的信息：

特定软件包的构建信息。怎样获取源代码和补丁？怎样构建，用Makefile还是Autotool？需要向目标编译环境输出哪些文件？需要安装哪些文件？每个软件包都需要描述文件。事实上，每个软件包的不同版本都有一个描述文件。

软件包之间的依赖关系。构建软件包A需要先构建什么主机平台工具，什么目标平台工具？软件包A在编译时依赖哪些软件包？软件包A在运行时依赖哪些软件包？一个目标应包含那些软件包？这些依赖关系把几百个软件包联系在一起，构成了一个完整的系统。

脚本和数据本来是一起打天下的。随着系统的完善，两者的独立性越来越强，就像《围城》中灌满了泥浆的裤子可以不依赖主人的腿而独自站立一样，数据和脚本也希望脱离对方独立发展。希望独立的脚本被称作bitbake。希望独立的数据就是OE元数据。

2.2 bitbake和OE元数据

可以把bitbake看作实现具体步骤的烹饪工具。把元数据看作食谱。如果只有烹饪工具，没有食谱，我们不知道要做什么。如果只有食谱，没有烹饪工具，就无法完成具体操作。

作为烹饪工具的bitbake是构建系统中代表稳定的部分。各种烹饪工具可以日趋完善，食谱可以随意选择自己需要的工具。

作为食谱的OE元数据是构建系统中代表变化的部分。变化来自两个方面：

虽然食谱系统不断完善，包含了大多数嵌入式系统可能用到的软件包。但还是会有新的软件包被开发出来。已有的软件包也会出新版本

每个系统总有自己独特的爱好和口味。Openmoko和Poky是定制过的OE环境。它们所定制的就是OE元数据。

Openmoko根据手机平台的需要，增加和定制了一些软件包，以及软件包的依赖关系。

Poky的主要风格是精简的GTK+/Macthbox系统。Openmoko环境有5千多个食谱文件，poky环境只有7百多个食谱文件。

我们可以根据自己的需要定制自己的元数据。Openmoko和poky都是不错的起点。一个不错的选择是以poky为起点，再从openmoko中取己所需。当然，我们总要根据设计目标开发特有的应用。

3文件系统里的OpenEmbedded

OE环境中最重要的目录有3个：放工具的bitbake目录、放元数据的目录、和执行构建的build目录。

3.1 bitbake目录

这个目录里是我们的烹饪工具：bitbake。我们使用它，但通常不需要访问它

3.2 元数据目录

在poky中元数据目录是meta。Openmoko中元数据目录是openembedded。在元数据目录中，有3个目录里是真正的元数据。它们是：classes、conf和packages。

3.2.1 packages目录

所有的食谱文件（以.bb为后缀名）都放在package目录。每个相对独立的软件包或构建任务在package目录下都有自己的子目录。在一个子目录中可以有多个食谱文件。它们可能是同一个软件包的不同版本。也可能描述了基于同一个软件包的不同构建目标。

有的食谱简单,有的食谱复杂。简单的食谱仅描述一个软件包的构建。最复杂的食谱就是要求构建文件系统的食谱，例如poky环境中的poky-image-sato，openmoko中的openmoko-devel-image。这个食谱文件本身并不长，甚至还很短，但它通过依赖关系将几百个甚至几千个其它食谱文件卷入了构建过程。 packages目录的images子目录下就是这些要求构建文件系统的食谱。

3.2.2 classes目录

这个目录放的是食谱的类文件（以.bbclass为后缀名）。类文件包含了一些bitbake任务的定义，例如怎么配置、怎么安装。食谱文件继承类文件，就继承了这些任务的定义。例如：我们如果增加一个使用autotool的软件包，只要在食谱文件中继承autotools.bbclass：inherit autotools

bitbake就知道怎样使用autotool工具配置、编译、安装了。所有的食谱文件都自动继承了base.bbclass。 base.bbclass提供了大部分bitbake任务的默认实现。

一个食谱文件可以继承多个类文件。以后的文章会介绍bitbake的任务，届时会更详细地讨论bitbake的继承。目前，我们只要知道继承类文件是一种构建过程的复用方式就可以了。

3.2.3 conf目录

conf目录包含编译系统的配置文件（以.conf为后缀名）。bitbake在启动时会执行bitbake.conf。

bitbake.conf会装载用户提供的local.conf。然后根据用户在local.conf中定义的硬件平台（MACHINE）和发布目标（DISTRO）装载machine子目录和distro子目录的配置文件。

machine子目录里是硬件平台相关的配置文件。distro子目录里是与发布目标相关的配置文件。配置文件负责设置bitbake内部使用的环境变量。这些变量会影响整个构建过程。

3.3 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目录。

3.3.1 staging目录

软件包B在构建时可能依赖软件包A提供的头文件、库文件，也可能要使用软件包C生成的工具。 staging目录就是放这些输出文件的地方。

我们必须在食谱文件中用“DEPENDS”变量声明构建时的依赖关系。

bitbake就会在构建软件包B前先构建软件包A和软件包C，并将软件包B需要的头文件、库文件、和工具放在staging目录。这样，在构建软件包B时就可以从staging目录得到需要的头文件、库文件、和工具。

3.3.2 work目录

所有软件包的解包、打补丁、配置、编译、安装等工作都是在work目录进行的。所以work目录包含了整个嵌入式系统的完整源代码。

work目录下按照硬件平台、发行人、目标平台的不同又分了几个子目录。所有软件包都被放在对应子目录中。每个软件包都有一个独立的目录。因为软件包总是

根据一个食谱文件构建的，所以软件包所在的目录就是对应食谱文件的工作目录。在讨论bitbake和食谱文件时我们还会回来，更仔细地观察食谱文件的工作

目录。

3.3.3 deploy目录

这是保存输出成果的目录。其中images目录保存构建成功后产生的文件系统映像、内核映像。 ipk目录保存每个软件包的安装包。我们在修改、构建软件包后，可以在目标平台手工安装ipk目录下的对应安装包。确认没有问题后，再制作文件系统映像。

3.3.4 stamps目录

和work目录类似，stamps目录也按照硬件平台、发行人、目标平台的不同又分了几个子目录。软件包在完成每个bitbake任务后都会在对应子目录里touch一个对应任务的时间戳。有时我们会手工删除某个软件包的时间戳，强制bitbake重新构建这个软件包。

3.4 sources目录

OE环境的sources目录是一个储藏间，用来放从网上下载的源代码包。 fetch任务负责下载代码，放到sources目录。

我通常在OE目录树之外创建一个公共sources目录。然后在OE目录创建一个软链接指向这个sources目录。这样，如果我同时在多个OE环境编译多个版本，这些OE环境的sources目录可以指向同一个公共sources目录。我让openmoko和poky也使用同一个公共sources目录。这样，大量构建系统所需的的软件包被保存在公共sources目录。在重新编译一个目标版本时，可以节省下载时间。在没有外网连接时也能完成整个构建过程。以后，即使有些软件包的链接失效了，我们还是可以构建完整的系统。

4 结束语

在自动化嵌入式系统构建过程的同时，OpenEmbedded 把前人的构建经验用脚本的形式记录下来。我们可以通过阅读OE脚本更直观地学习怎样构建一个嵌入式系统。

无论在windows、linux、还是RTOS上，也无论使用C/C++、Java、还是脚本，程序员总是在将变化从不变中分离出来。

OpenEmbedded 已经将脚本和元数据分离开来，将变化的元数据和不变的元数据分离开来。如果OpenEmbedded能更有效地区分必须的关联和可选的关联，将关联的配置相对集中起来，定制系统可能会更简单。

本文是OpenEmbedded 的简单介绍，下面我们将进一步了解bitbake世界的风土人情，食谱文件的规则、惯例，在tmp/work目录中究竟发生了什么。后面的文章假设读者已经编译、运行过poky或openmoko。本文的例子主要基于poky。

不管Openmoko和OpenedHand（poky的开发者，已被Intel收购）如何发展，放在我们面前的是一套完整的嵌入式Linux方案。只要我们愿意，我们可以看到这个系统的每个细节，每行代码，包括构建系统本身的每行脚本。