1 概述
OpenEmbedded（OE）是一個開源的嵌入式linux系統構建環境。 Openmoko和poky都使用了定製過的OpenEmbedded環境。 Openmoko是一個開放軟硬件設計的手機平臺。Poky的本意是一個定製過的OpenEmbedded環境。 Poky環境包含了一個叫作Sato的UI方案，我們有時也把這個方案叫作poky。其實我們可以在poky環境開發其它基於GTK+/Macthbox的UI方案。
構建一個嵌入式linux系統需要構建引導模塊、內核和文件系統。這是一個相當複雜的過程，特別是文件系統的構建。一個典型的文件系統可能需要下載、編譯、安裝幾百個軟件包。如果你做過LFS（Linux From Scratch），就可以體會到手工創建文件系統的複雜性。嵌入式系統因爲是交叉編譯（在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方案。只要我們願意，我們可以看到這個系統的每個細節，每行代碼，包括構建系統本身的每行腳本。
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/fmddlmyy/archive/2008/11/08/3254033.aspx