參考:http://www.yoctoproject.org/docs/2.4/bitbake-user-manual/bitbake-user-manual.html
1. 概述
歡迎使用Bitbake用戶手冊。本手冊提供Bitbake工具的相關(guān)信息。這些信息盡可能獨(dú)立于使用Bitbake的系統(tǒng),如OpenEmbedded和Yocto Project。在某些情況下,本手冊將使用構(gòu)建系統(tǒng)中的場景或示例來幫助理解。對于這些情況,手冊清楚地說明的使用上下文。
1.1.介紹
從根本上說,Bitbake是一個(gè)通用任務(wù)執(zhí)行引擎,允許shell和python任務(wù)在復(fù)雜的任務(wù)間依賴約束條件下高效并行運(yùn)行。Bitbake的主要用戶之一,OpenEmbedded,采用Bitbake,并使用面向任務(wù)的方法構(gòu)建嵌入式Linux軟件棧。
從概念上講,Bitbake在某些方面類似于GNU Make,但具有顯著差異:
Bitbake根據(jù)提供的構(gòu)建任務(wù)的元數(shù)據(jù)執(zhí)行任務(wù)。元數(shù)據(jù)存儲(chǔ)在配方(.bb)和相關(guān)配方“append”(.bbappend)文件,配置(.conf)和底層包含(.inc)文件以及類(.bbclass)文件中。元數(shù)據(jù)為Bitbake提供了有關(guān)運(yùn)行哪些任務(wù)以及這些任務(wù)之間的依賴說明。
Bitbake包含一個(gè)程序庫用于從各種地方(如本地文件,源碼管理系統(tǒng)或網(wǎng)站)獲取源代碼。
每個(gè)要構(gòu)建的單元(例如一個(gè)軟件)的指令被稱為“配方”文件,并且包含關(guān)于該單元的所有信息(依賴性,源文件位置,校驗(yàn)和,描述等扥)。
Bitbake包含客戶端/服務(wù)器抽象,可以通過命令行使用或者通過XML-RPC作為服務(wù)提供,并具有多個(gè)不同的用戶界面。
1.2.歷史和目標(biāo)
BitBake最初是OpenEmbedded項(xiàng)目的一部分。 它受到了Linux發(fā)行版Gentoo使用的Portage包管理系統(tǒng)的啟發(fā)。2004年12月7日,OpenEmbedded項(xiàng)目組成員克里斯·拉森(Chris Larson)將項(xiàng)目分為兩個(gè)截然不同的部分:
BitBake,通用任務(wù)執(zhí)行程序
OpenEmbedded,由BitBake使用的元數(shù)據(jù)集
如今,BitBake是OpenEmbedded項(xiàng)目的主要基礎(chǔ),它被用來構(gòu)建和維護(hù)諸如Angstrom之類的Linux發(fā)行版,并且也被用作諸如Yocto項(xiàng)目之類的Linux項(xiàng)目的構(gòu)建工具。
在BitBake之前,沒有其他的構(gòu)建工具能夠充分滿足有抱負(fù)的嵌入式Linux發(fā)行版的需求。傳統(tǒng)桌面Linux發(fā)行版所使用的所有構(gòu)建系統(tǒng)都缺乏重要的功能,并且在嵌入式領(lǐng)域中普遍使用的基于Buildroot的系統(tǒng)都不具備可擴(kuò)展性或可維護(hù)性。
BitBake最初的一些重要目標(biāo)包括:
處理交叉編譯。
處理包間依賴(包括在目標(biāo)架構(gòu)上構(gòu)建時(shí)的依賴,在本機(jī)架構(gòu)上構(gòu)建時(shí)的依賴及運(yùn)行時(shí)依賴)。
支持在給定包中運(yùn)行任意數(shù)量的任務(wù),包括但不限于獲取上游源碼,解壓縮,打補(bǔ)丁,配置等等。
對于構(gòu)建和目標(biāo)系統(tǒng),不假設(shè)使用什么Linux發(fā)行版。
不假設(shè)使用什么架構(gòu)。
支持多種構(gòu)建和目標(biāo)操作系統(tǒng)(如Cygwin,BSD等)。
自我包容,而不是緊密集成到生的機(jī)器的根文件系統(tǒng)。
根據(jù)目標(biāo)架構(gòu),操作系統(tǒng),發(fā)行版和機(jī)器處理?xiàng)l件元數(shù)據(jù)。
方便使用這些工具來提供本地元數(shù)據(jù)和包。
方便使用BitBake在多個(gè)項(xiàng)目之間為其構(gòu)建進(jìn)行協(xié)作。
提供一個(gè)繼承機(jī)制來共享許多包之間的通用元數(shù)據(jù)。
隨著時(shí)間的推移,還需要進(jìn)一步的要求:
處理基本配方的變體(例如native,sdk和multilib)。
將元數(shù)據(jù)拆分成圖層,并允許圖層增強(qiáng)或覆蓋其他圖層。
允許將給定的一組輸入變量表示為一個(gè)校驗(yàn)和。基于該校驗(yàn)和,允許使用預(yù)先構(gòu)建的組件加速構(gòu)建。
BitBake滿足了所有的原始要求,還有更多的擴(kuò)展是基本的功能來反映附加的要求。靈活性和權(quán)力一直是優(yōu)先事項(xiàng)。BitBake具有高度的可擴(kuò)展性,支持嵌入式Python代碼和執(zhí)行任意任務(wù)。
1.3.概念
BitBake是一個(gè)用Python語言編寫的程序。在最頂層,BitBake解釋元數(shù)據(jù),決定哪些任務(wù)需要運(yùn)行,并執(zhí)行這些任務(wù)。與GNU Make類似,BitBake控制軟件的構(gòu)建方式。GNU Make通過“makefile”實(shí)現(xiàn)控制,而BitBake使用“recipes”。
BitBake擴(kuò)展了像GNU Make這樣的簡單工具的功能,允許定義更復(fù)雜的任務(wù),比如組裝整個(gè)嵌入式Linux發(fā)行版。
本節(jié)的其余部分介紹了為了更好地利用BitBake的功能應(yīng)該理解的幾個(gè)概念。
1.3.1. 配方Recipes
以文件擴(kuò)展名.bb表示的BitBake Recipes是最基本的元數(shù)據(jù)文件。這些配方文件為BitBake提供了以下內(nèi)容:
關(guān)于軟件包的描述性信息(作者,主頁,許可證等)
配方的版本
現(xiàn)有的依賴關(guān)系(包括構(gòu)建和運(yùn)行時(shí)依賴關(guān)系)
源代碼駐留在哪里以及如何獲取它
源代碼是否需要任何補(bǔ)丁,在哪里可以找到它們,以及如何應(yīng)用它們
如何配置和編譯源代碼
在目標(biāo)機(jī)器上安裝所創(chuàng)建的軟件包或軟件包的位置
在BitBake或任何使用BitBake作為其構(gòu)建系統(tǒng)的項(xiàng)目中,具有.bb擴(kuò)展名的文件被稱為配方。
注意:“package”一詞通常也用來描述配方。但是,由于這個(gè)詞用來描述項(xiàng)目的打包輸出,因此保留一個(gè)描述性術(shù)語-“recipes”。換句話說,一個(gè)單獨(dú)的“配方”文件相當(dāng)有能力生成一些相關(guān)但可單獨(dú)安裝的“包”。事實(shí)上,這種能力是相當(dāng)普遍的。
1.3.2. 配置文件
配置文件(由.conf擴(kuò)展名表示)定義了管理項(xiàng)目構(gòu)建過程的各種配置變量。 這些文件分為幾個(gè)領(lǐng)域,定義了機(jī)器配置選項(xiàng),分發(fā)配置選項(xiàng),編譯器調(diào)整選項(xiàng),通用配置選項(xiàng)和用戶配置選項(xiàng)。 主配置文件是位于BitBake源碼conf目錄中的示例bitbake.conf文件。
1.3.3. 類
類文件(由.bbclass擴(kuò)展名表示)包含有助于在元數(shù)據(jù)文件之間共享的信息。BitBake源碼當(dāng)前帶有一個(gè)名為base.bbclass的類元數(shù)據(jù)文件。你可以在classes目錄下找到這個(gè)文件。base.bbclass類文件是特殊的,因?yàn)樗偸亲詣?dòng)包含在所有的配方和類中。這個(gè)類包含了標(biāo)準(zhǔn)的基本任務(wù)的定義,例如抓取,解包,配置(默認(rèn)為空),編譯(運(yùn)行任何Makefile),安裝(默認(rèn)為空)和打包(默認(rèn)為空)。這些任務(wù)通常被項(xiàng)目開發(fā)過程中添加的其他類所覆蓋或擴(kuò)展。
1.3.4. 層
層允許您隔離不同類型的自定義。雖然在單個(gè)項(xiàng)目中工作時(shí),您可能會(huì)將所有內(nèi)容都保存在一個(gè)層次上,但是您將元數(shù)據(jù)組織得越模塊化,越容易處理未來的變化。
為了說明如何使用圖層來保持模塊化,考慮您可能為支持特定目標(biāo)計(jì)算機(jī)而進(jìn)行的自定義。這些類型的自定義通常駐留在特殊層中,而不是稱為板級(jí)支持包(BSP)層的通用層。此外,例如,機(jī)器自定義應(yīng)該與支持新的GUI環(huán)境的配方和元數(shù)據(jù)隔離。這種情況下你會(huì)有幾個(gè)圖層:一個(gè)用于機(jī)器配置,另一個(gè)用于GUI環(huán)境。但是,理解BSP層仍然可以在GUI環(huán)境層中為機(jī)器添加配方,而不會(huì)使用特定于機(jī)器的更改污染GUI層本身,這一點(diǎn)很重要。您可以通過BitBake附加(.bbappend)文件的配方完成此操作。
1.3.5. 附加文件
附加文件是具有.bbappend文件擴(kuò)展名的文件,擴(kuò)展或覆蓋現(xiàn)有配方文件中的信息。
BitBake期望每個(gè)附加文件都有相應(yīng)的配方文件。此外,附加文件和相應(yīng)的配方文件必須使用相同的根文件名。文件名只能在所使用的文件類型后綴上有所不同(例如formfactor_0.0.bb和formfactor_0.0.bbappend)。
附加文件中的信息擴(kuò)展或覆蓋底層的,類似名稱的配方文件中的信息。
在命名附加文件時(shí),可以使用通配符(%)來匹配配方名稱。例如,假設(shè)您有一個(gè)如下所示的附加文件:
busybox_1.21%.bbappend
該附加文件將匹配任何busybox_1.21.x.bb版本的配方。所以,附加文件將匹配以下配方名稱:
busybox_1.21.1.bb
busybox_1.21.2.bb
busybox_1.21.3.bb
如果busybox配方更新為busybox_1.3.0.bb,則附加名稱不匹配。但是,如果您將追加文件命名為busybox_1.%.bbappend,那么您將有一個(gè)匹配項(xiàng)。
在最一般的情況下,你可以命名附加文件像busybox _%.bbappend一樣簡單,完全獨(dú)立于版本。
1.4.獲取Bitbake
您可以通過幾種不同的方式獲取BitBake:
-
Clone BitBake:推薦使用Git工具Clone BitBake源代碼庫是獲取BitBake。Clone repo可以很容易地獲得錯(cuò)誤修復(fù),并有權(quán)訪問穩(wěn)定的分支和主分支。一旦你有了BitBake的clone,你應(yīng)該使用最新的穩(wěn)定分支進(jìn)行開發(fā),因?yàn)橹鞣种怯糜贐itBake開發(fā)的,并且可能包含不太穩(wěn)定的變化。
您通常需要與您正在使用的元數(shù)據(jù)相匹配的BitBake版本。元數(shù)據(jù)通常是向后兼容的,但不能向前兼容。
以下是一個(gè)Clone BitBake Repo的例子:$ git clone git://git.openembedded.org/bitbake</pre>
該命令將BitBake Git Repo Clone到一個(gè)名為bitbake的目錄中。或者,你也可以在git clone命令后指定一個(gè)目錄。如下例,命名目錄bbdev:
$ git clone git://git.openembedded.org/bitbake bbdev</pre>
使用您的分發(fā)包管理系統(tǒng)進(jìn)行安裝:不建議使用此方法,因?yàn)槟陌l(fā)行版提供的BitBake版本在大多數(shù)情況下是在BitBake Repo之前的多個(gè)版本。
-
獲取BitBake快照:從源代碼庫下載BitBake的快照,可以訪問已知的BitBake分支或版本。
注意:如前所述,Clone Git Repo是獲取BitBake的首選方法。克隆存儲(chǔ)庫使修補(bǔ)程序添加到穩(wěn)定分支時(shí)更容易更新。
以下示例下載BitBake版本1.17.0的快照:
$ wget http://git.openembedded.org/bitbake/snapshot/bitbake-1.17.0.tar.gz</pre>
使用tar實(shí)用程序解壓縮tarball之后,您將擁有一個(gè)名為bitbake-1.17.0的目錄。
使用您的Build Checkout附帶的BitBake:獲取BitBake副本的最后一個(gè)可能性是它已經(jīng)附帶了一個(gè)更大的基于Bitbake的構(gòu)建系統(tǒng)(如Poky或Yocto Project)的checkout。您可以檢查出整個(gè)構(gòu)建系統(tǒng),而不是手動(dòng)檢查各個(gè)圖層并將它們粘貼在一起。checkout已經(jīng)包含了一個(gè)BitBake的版本,已經(jīng)過了與其他組件的兼容性測試。有關(guān)如何檢出特定的基于BitBake的構(gòu)建系統(tǒng)的信息,請參閱構(gòu)建系統(tǒng)的支持文檔。
1.5.Bitbake命令
bitbake命令是BitBake工具的主要接口。 本節(jié)介紹BitBake命令語法并提供了幾個(gè)執(zhí)行示例。
1.5.1. 用法和語法
以下是Bitbake命令的用法和語法:
dp@Ubuntu:/home/skunlin/openbmc/build$ bitbake -h
Usage: bitbake [options] [recipename/target recipe:do_task ...]
Executes the specified task (default is 'build') for a given set of target recipes (.bb files).
It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH which
will provide the layer, BBFILES and other configuration information.
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-b BUILDFILE, --buildfile=BUILDFILE
Execute tasks from a specific .bb recipe directly.
WARNING: Does not handle any dependencies from other
recipes.
-k, --continue Continue as much as possible after an error. While the
target that failed and anything depending on it cannot
be built, as much as possible will be built before
stopping.
-a, --tryaltconfigs Continue with builds by trying to use alternative
providers where possible.
-f, --force Force the specified targets/task to run (invalidating
any existing stamp file).
-c CMD, --cmd=CMD Specify the task to execute. The exact options
available depend on the metadata. Some examples might
be 'compile' or 'populate_sysroot' or 'listtasks' may
give a list of the tasks available.
-C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMP
Invalidate the stamp for the specified task such as
'compile' and then run the default task for the
specified target(s).
-r PREFILE, --read=PREFILE
Read the specified file before bitbake.conf.
-R POSTFILE, --postread=POSTFILE
Read the specified file after bitbake.conf.
-v, --verbose Output more log message data to the terminal.
-D, --debug Increase the debug level. You can specify this more
than once.
-q, --quiet Output less log message data to the terminal.
-n, --dry-run Don't execute, just go through the motions.
-S SIGNATURE_HANDLER, --dump-signatures=SIGNATURE_HANDLER
Dump out the signature construction information, with
no task execution. The SIGNATURE_HANDLER parameter is
passed to the handler. Two common values are none and
printdiff but the handler may define more/less. none
means only dump the signature, printdiff means compare
the dumped signature with the cached one.
-p, --parse-only Quit after parsing the BB recipes.
-s, --show-versions Show current and preferred versions of all recipes.
-e, --environment Show the global or per-recipe environment complete
with information about where variables were
set/changed.
-g, --graphviz Save dependency tree information for the specified
targets in the dot syntax.
-I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED
Assume these dependencies don't exist and are already
provided (equivalent to ASSUME_PROVIDED). Useful to
make dependency graphs more appealing
-l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
Show debug logging for the specified logging domains
-P, --profile Profile the command and save reports.
-u UI, --ui=UI The user interface to use (depexp, knotty or ncurses -
default knotty).
-t SERVERTYPE, --servertype=SERVERTYPE
Choose which server type to use (process or xmlrpc -
default process).
--token=XMLRPCTOKEN Specify the connection token to be used when
connecting to a remote server.
--revisions-changed Set the exit code depending on whether upstream
floating revisions have changed or not.
--server-only Run bitbake without a UI, only starting a server
(cooker) process.
--foreground Run bitbake server in foreground.
-B BIND, --bind=BIND The name/address for the bitbake server to bind to.
-T IDLE_TIMEOUT, --idle-timeout=IDLE_TIMEOUT
Set timeout to unload bitbake server due to inactivity
--no-setscene Do not run any setscene tasks. sstate will be ignored
and everything needed, built.
--setscene-only Only run setscene tasks, don't run any real tasks.
--remote-server=REMOTE_SERVER
Connect to the specified server.
-m, --kill-server Terminate the remote server.
--observe-only Connect to a server as an observing-only client.
--status-only Check the status of the remote bitbake server.
-w WRITEEVENTLOG, --write-log=WRITEEVENTLOG
Writes the event log of the build to a bitbake event
json file. Use '' (empty string) to assign the name
automatically.
1.5.2. 示例
本節(jié)介紹一些如何使用BitBake的例子。
1.5.2.1. 針對單個(gè)配方執(zhí)行任務(wù)
執(zhí)行單個(gè)配方文件的任務(wù)相對簡單。您指定有要求的文件,BitBake解析它并執(zhí)行指定的任務(wù)。如果你沒有指定一個(gè)任務(wù),BitBake會(huì)執(zhí)行默認(rèn)的任務(wù),即“build”,BitBake在這個(gè)過程中服從于任務(wù)間的依賴關(guān)系。
以下命令在foo_1.0.bb配方文件上運(yùn)行構(gòu)建任務(wù)(默認(rèn)任務(wù)):
$ bitbake -b foo_1.0.bb
以下命令在foo.bb配方文件上運(yùn)行clean任務(wù):
$ bitbake -b foo.bb -c clean
注意:“-b”選項(xiàng)顯式不處理配方依賴關(guān)系。除了出于調(diào)試的目的,建議您使用下一節(jié)中介紹的語法。
1.5.2.2. 對一組配方文件執(zhí)行任務(wù)
當(dāng)需要管理多個(gè).bb文件時(shí),會(huì)引入一些其他的復(fù)雜性。顯然,需要有一種方法可以告訴BitBake哪些文件可用,哪些是您想要執(zhí)行的文件。每個(gè)配方還需要有一種方法來表達(dá)它的依賴關(guān)系,無論是構(gòu)建時(shí)依賴還是運(yùn)行時(shí)依賴。當(dāng)多個(gè)配方提供相同的功能時(shí),或者有多個(gè)配方版本時(shí),必須有一種方法可以表達(dá)配方首選項(xiàng)。
當(dāng)不使用“--buildfile”或“-b”時(shí),bitbake命令只接受“PROVIDES”。你不能提供任何其他的東西。默認(rèn)情況下,配方文件通常“提供”其“包名”,如下所示:
$ bitbake foo
下一個(gè)示例“提供”包名稱,并使用“-c”選項(xiàng)告訴BitBake只執(zhí)行do_clean任務(wù):
$ bitbake -c clean foo
1.5.2.3. 執(zhí)行任務(wù)和配方組合表
當(dāng)您指定多個(gè)目標(biāo)時(shí),BitBake命令行支持為各個(gè)目標(biāo)指定不同的任務(wù)。例如,假設(shè)您有兩個(gè)目標(biāo)(或配方)myfirstrecipe和mysecondrecipe,并且需要BitBake為第一個(gè)配方執(zhí)行tashA,為第二個(gè)配方執(zhí)行taskB:
$ bitbake myfirstrecipe:do_taskA mysecondrecipe:do_taskB
1.5.2.4. 生成依賴圖
BitBake能夠使用dot生成依賴關(guān)系圖。 您可以使用Graphviz中的dot工具將這些圖轉(zhuǎn)換為圖片。
當(dāng)您生成依賴關(guān)系圖時(shí),BitBake將三個(gè)文件寫入當(dāng)前工作目錄:
recipe-depends.dot:顯示配方之間的依賴關(guān)系(即task-depends.dot的折疊版本)。
task-depends.dot:顯示任務(wù)之間的依賴關(guān)系。 這些依賴與BitBake的內(nèi)部任務(wù)執(zhí)行列表相匹配。
pn-buildlist:顯示要構(gòu)建的目標(biāo)的簡單列表。
使用“-I”于選項(xiàng)省略指定部分的依賴關(guān)系。刪除這些信息可以產(chǎn)生更多可讀的圖表。
以下是創(chuàng)建依賴關(guān)系圖的兩個(gè)示例。 第二個(gè)例子在OpenEmbedded中常見:
$ bitbake -g foo
$ bitbake -g -I virtual/kernel -I eglibc foo
2. 執(zhí)行
運(yùn)行BitBake的主要目的是生成一些輸出,比如一個(gè)可安裝的軟件包,一個(gè)內(nèi)核,一個(gè)軟件開發(fā)工具包,甚至一個(gè)完整的特定于電路板的可引導(dǎo)的Linux映像,包括引導(dǎo)加載程序,內(nèi)核和根文件系統(tǒng)。當(dāng)然,你可以執(zhí)行帶有選項(xiàng)的bitbake命令,這些選項(xiàng)可以執(zhí)行單個(gè)任務(wù),編譯單個(gè)配方文件,捕獲或清除數(shù)據(jù),或者簡單地返回有關(guān)執(zhí)行環(huán)境的信息。
本章介紹BitBake的執(zhí)行過程,當(dāng)您使用它來創(chuàng)建image時(shí),從開始到結(jié)束。執(zhí)行過程使用以下命令形式啟動(dòng):
$ bitbake target
有關(guān)BitBake命令及其選項(xiàng)的信息,請參閱“BitBake命令”部分。
注意:在執(zhí)行BitBake之前,您應(yīng)該通過在您的項(xiàng)目的local.conf配置文件中設(shè)置BB_NUMBER_THREADS變量來利用您的構(gòu)建主機(jī)上可用的并行線程執(zhí)行。
為生成主機(jī)確定此值的常用方法是運(yùn)行以下命令:
$ grep processor / proc / cpuinfo
這個(gè)命令返回處理器的數(shù)量,這考慮到了超線程。 因此,具有超線程的四核主機(jī)很可能會(huì)顯示八個(gè)處理器,這是您將分配給BB_NUMBER_THREADS的值。
一個(gè)可能更簡單的解決方案是某些Linux發(fā)行版(例如Debian和Ubuntu)提供了ncpus命令。
2.1.解析基本配置元數(shù)據(jù)
BitBake做的第一件事是解析基本配置元數(shù)據(jù)。基本配置元數(shù)據(jù)由項(xiàng)目的bblayers.conf文件組成,以確定BitBake需要識(shí)別的層,所有必需的layer.conf文件(每層一個(gè))以及bitbake.conf。數(shù)據(jù)本身有各種類型:
配方:關(guān)于特定的軟件的細(xì)節(jié)。
類數(shù)據(jù):常見構(gòu)建信息的抽象(例如,如何構(gòu)建Linux內(nèi)核)。
配置數(shù)據(jù):特定于機(jī)器的設(shè)置,策略決策等等。配置數(shù)據(jù)充當(dāng)了將所有東西綁定在一起的粘合劑。
layer.conf文件用于構(gòu)建關(guān)鍵變量,如BBPATH和BBFILES。BBPATH用于分別在conf和classes目錄下搜索配置和類文件。BBFILES用于定位配方和配方附加文件(.bb和.bbappend)。如果沒有bblayers.conf文件,則假定用戶已經(jīng)在環(huán)境中直接設(shè)置了BBPATH和BBFILES。
接下來,使用剛剛構(gòu)建的BBPATH變量來定位bitbake.conf文件。bitbake.conf文件也可能包含使用include或require指令的其他配置文件。
在解析配置文件之前,Bitbake會(huì)查看某些變量,包括:
- BB_ENV_WHITELIST
- BB_ENV_EXTRAWHITE
- BB_PRESERVE_ENV
- BB_ORIGENV
- BITBAKE_UI
該列表中的前四個(gè)變量與BitBake在任務(wù)執(zhí)行期間如何處理shell環(huán)境變量有關(guān)。默認(rèn)情況下,BitBake清理環(huán)境變量,并嚴(yán)格控制shell執(zhí)行環(huán)境。但是,通過使用這些前四個(gè)變量,您可以在執(zhí)行任務(wù)期間應(yīng)用您的空間,獲取在shell中允許由Bitbake使用的環(huán)境變量。請參閱“將信息傳遞到構(gòu)建任務(wù)環(huán)境”一節(jié)以及變量術(shù)語表中有關(guān)這些變量的信息,以獲取有關(guān)這些變量如何工作以及如何使用它們的更多信息。
基本配置元數(shù)據(jù)是全局的,因此會(huì)影響所有執(zhí)行的配方和任務(wù)。
BitBake首先在當(dāng)前工作目錄中搜索一個(gè)可選的conf / bblayers.conf配置文件。這個(gè)文件應(yīng)該包含一個(gè)BBLAYERS變量,它是一個(gè)空格分隔的“層”目錄列表。如果BitBake找不到bblayers.conf文件,那么假定用戶已經(jīng)在環(huán)境中直接設(shè)置了BBPATH和BBFILES變量。
對于此列表中的每個(gè)目錄(層),將找到一個(gè)conf / layer.conf文件并將LAYERDIR變量傳給它,變量值設(shè)置為圖層所在的目錄。目的是這些文件會(huì)自動(dòng)為給定的構(gòu)建目錄設(shè)置BBPATH和其他變量。
然后,BitBake希望在用戶指定的BBPATH中找到conf / bitbake.conf文件。該配置文件通常包含指令來引入任何其他元數(shù)據(jù),例如特定于架構(gòu),機(jī)器,本地環(huán)境等的文件。
在BitBake .conf文件中只允許使用變量定義和包含指令。有些變量直接影響B(tài)itBake的行為。這些變量可能是根據(jù)前面提到的或在配置文件中設(shè)置的環(huán)境變量從環(huán)境中設(shè)置的。“變量術(shù)語”一章介紹了變量的完整列表。
解析配置文件后,BitBake使用其基本的繼承機(jī)制,通過類文件,繼承一些標(biāo)準(zhǔn)的類。當(dāng)遇到負(fù)責(zé)獲取那個(gè)類的繼承指令時(shí),BitBake解析一個(gè)類。
base.bbclass文件始終包含在內(nèi)。還包括使用INHERIT變量在配置中指定的其他類。BitBake以與配置文件相同的方式在BBPATH中的路徑下的類子目錄中搜索類文件。
了解執(zhí)行環(huán)境中使用的配置文件和類文件的一個(gè)好方法是運(yùn)行以下BitBake命令:
$ bitbake -e> mybb.log</pre>
檢查mybb.log的頂部將顯示執(zhí)行環(huán)境中使用的許多配置文件和類文件。
注意:您需要了解BitBake如何分析花括號(hào)。 如果一個(gè)配方在函數(shù)中使用了一個(gè)大括號(hào),并且該字符沒有前導(dǎo)空格,BitBake會(huì)產(chǎn)生解析錯(cuò)誤。 如果在外殼功能中使用一對花括號(hào),則不能在沒有前導(dǎo)空格的行的起始位置放置關(guān)閉的大括號(hào)。
這是一個(gè)導(dǎo)致BitBake產(chǎn)生解析錯(cuò)誤的例子:
fakeroot create_shar() {
cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
usage()
{
echo "test"
###### The following "}" at the start of the line causes a parsing error ######
}
EOF
}
用這種方法寫配方避免了這個(gè)錯(cuò)誤:
fakeroot create_shar() {
cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
usage()
{
echo "test"
######The following "}" with a leading space at the start of the line avoids the error ######
}
EOF
}
2.2.查找和分析配方
在配置階段,BitBake將會(huì)設(shè)置BBFILES。BitBake現(xiàn)在使用它來構(gòu)建一個(gè)解析的配方列表,以及所有使用的附加文件(.bbappend)。BBFILES是可用文件的空格分隔列表,并支持通配符。一個(gè)例子如下:
BBFILES =“/path/to/bbfiles/*.bb /path/to/appends/*.bbappend”
BitBake解析BBFILES中的每個(gè)配方及附加文件,并將各種變量的值存儲(chǔ)到數(shù)據(jù)存儲(chǔ)中。
附加文件按照在BBFILES中出現(xiàn)的順序應(yīng)用。
對于每個(gè)文件,創(chuàng)建基本配置的全新副本,然后逐行分析配方。任何繼承語句都會(huì)觸發(fā)BitBake使用BBPATH作為搜索路徑來查找并解析類文件(.bbclass)。最后,BitBake按順序解析在BBFILES中找到的任何附加文件。
一個(gè)常見的約定是使用配方文件名來定義元數(shù)據(jù)。例如,在bitbake.conf中,配方名稱和版本用于設(shè)置變量PN和PV:
PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}"
PV = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
在這個(gè)例子中,一個(gè)名為“something_1.2.3.bb”的配方會(huì)將PN設(shè)置為“something”,將PV設(shè)置為“1.2.3”。
在配方完成解析之后,BitBake擁有配方定義的任務(wù)列表,以及由鍵和值組成的一組數(shù)據(jù)以及有關(guān)任務(wù)的相關(guān)性信息。
BitBake不需要所有這些信息。它只需要一小部分信息就可以決定配方。因此,BitBake會(huì)緩存它感興趣的值,而不會(huì)保存其余的信息。經(jīng)驗(yàn)表明,重新解析元數(shù)據(jù)要比試圖將其寫入磁盤然后重新加載更快。
在可能的情況下,后續(xù)的BitBake命令會(huì)重新使用這個(gè)配方信息緩存。首先計(jì)算基本配置數(shù)據(jù)的校驗(yàn)和(請參閱BB_HASHCONFIG_WHITELIST),然后檢查校驗(yàn)和是否匹配,從而確定此緩存的有效性。如果該校驗(yàn)和與緩存中的內(nèi)容匹配并且配方和類文件沒有更改,則Bitbake可以使用該緩存。然后BitBake重新加載有關(guān)配方的緩存信息,而不是從頭開始重新解析。
配方文件集合的存在使得用戶可以擁有包含相同的確切軟件包的.bb文件的多個(gè)存儲(chǔ)庫。例如,可以很容易地使用它們來創(chuàng)建上游存儲(chǔ)庫的本地副本,但可以使用自定義修改,而不需要上游。一個(gè)例子如下:
BBFILES = "/stuff/openembedded/*/*.bb /stuff/openembedded.modified/*/*.bb"
BBFILE_COLLECTIONS = "upstream local"
BBFILE_PATTERN_upstream = "^/stuff/openembedded/"
BBFILE_PATTERN_local = "^/stuff/openembedded.modified/"
BBFILE_PRIORITY_upstream = "5"
BBFILE_PRIORITY_local = "10"
注意:圖層機(jī)制現(xiàn)在是收集代碼的首選方法。 雖然集合代碼仍然存在,但其主要用途是設(shè)置圖層優(yōu)先級(jí)并處理圖層之間的重疊(沖突)。
2.3.Providers
假設(shè)BitBake已經(jīng)被指示執(zhí)行一個(gè)目標(biāo),并且所有的配方文件已經(jīng)被解析,BitBake開始計(jì)算出如何構(gòu)建目標(biāo)。BitBake通過PROVIDES列表查看每個(gè)配方。PROVIDES列表是可以知道配方的名稱列表。每個(gè)配方的PROVIDES列表通過配方的PN變量隱式創(chuàng)建,并通過配方的PROVIDES變量顯式創(chuàng)建,該變量是可選的。
當(dāng)配方使用PROVIDES時(shí),該配方的功能可以在隱式PN名稱以外的其他名稱下找到。例如,假設(shè)名為keyboard_1.0.bb的配方包含以下內(nèi)容:
PROVIDES += "fullkeyboard"
這個(gè)配方的PROVIDES列表變成了“鍵盤”,這是隱式的,“fullkeyboard”是顯示的。因此,可以在兩個(gè)不同的名稱下找到keyboard_1.0.bb中的功能。
2.4.Preferences
PROVIDES列表只是解決目標(biāo)配方的解決方案的一部分。由于目標(biāo)可能有多個(gè)providers,因此BitBake需要通過確定providers偏好來確定providers的優(yōu)先級(jí)。
目標(biāo)具有多個(gè)provider程序的常見示例是“virtual/kernel”,位于每個(gè)內(nèi)核配方的PROVIDERS列表上。每臺(tái)機(jī)器通常通過在機(jī)器配置文件中使用與以下內(nèi)容類似的一行來選擇最佳的內(nèi)核提供者:
PREFERRED_PROVIDER_virtual / kernel =“l(fā)inux-yocto”
默認(rèn)的PREFERRED_PROVIDER是與目標(biāo)名稱相同的provider。Bitbake遍歷每個(gè)需要構(gòu)建的目標(biāo),并使用這個(gè)過程解決它們及其依賴關(guān)系。
由于一個(gè)給定的provider可能存在多個(gè)版本,如何選擇provider就變得復(fù)雜了。BitBake默認(rèn)為provider的最高版本。版本比較使用與Debian相同的方法進(jìn)行。您可以使用PREFERRED_VERSION變量來指定特定的版本。您可以通過使用DEFAULT_PREFERENCE變量影響順序。
默認(rèn)情況下,文件的優(yōu)先級(jí)為“0”。將DEFAULT_PREFERENCE設(shè)置為“-1”將使得配方不太可能被使用到,除非它被明確引用。將DEFAULT_PREFERENCE設(shè)置為“1”可能會(huì)使用配方。 PREFERRED_VERSION將覆蓋任何DEFAULT_PREFERENCE設(shè)置。 DEFAULT_PREFERENCE通常用于標(biāo)記更新,更多實(shí)驗(yàn)測試的配方版本,直到經(jīng)過足夠的測試才能被認(rèn)為是穩(wěn)定的。
當(dāng)給定配方有多個(gè)“版本”時(shí),除非另有說明,BitBake默認(rèn)選擇最新的版本。如果所討論的配方的DEFAULT_PREFERENCE設(shè)置低于其他配方(默認(rèn)值為0),則不會(huì)被選中。這允許維護(hù)配方文件存儲(chǔ)庫的人員指定他們對默認(rèn)選定版本的偏好。另外,用戶可以指定他們的首選版本。
如果第一個(gè)配方命名為a_1.1.bb,則PN變量將被設(shè)置為“a”,并且PV變量將被設(shè)置為1.1。
因此,如果存在名為a_1.2.bb的配方,BitBake將默認(rèn)選擇1.2。但是,如果您在BitBake分析的.conf文件中定義以下變量,則可以更改該首選項(xiàng):
PREFERRED_VERSION_a =“1.1”
注意:一個(gè)配方通常提供兩個(gè)版本 - 一個(gè)穩(wěn)定的,編號(hào)(和首選)的版本,以及一個(gè)從源代碼庫自動(dòng)檢出的版本,這個(gè)版本被認(rèn)為是更為“bleeding edge”,但只能顯式選擇。
例如,在OpenEmbedded代碼庫中,BusyBox有一個(gè)標(biāo)準(zhǔn)版本配方文件busybox_1.22.1.bb,但也有一個(gè)基于Git的版本busybox_git.bb,它明確包含了行
DEFAULT_PREFERENCE =“-1”
以確保編號(hào)的穩(wěn)定版本始終是首選的,除非開發(fā)者另有選擇。
2.5.依賴
每個(gè)目標(biāo)BitBake構(gòu)建包括多個(gè)任務(wù),如提取,解包,修補(bǔ),配置和編譯。為了在多核系統(tǒng)上獲得最佳性能,BitBake將每個(gè)任務(wù)視為一個(gè)獨(dú)立的實(shí)體,并擁有自己的一套依賴關(guān)系。
依賴性通過幾個(gè)變量來定義。您可以在本手冊末尾的變量詞匯表中找到有關(guān)變量BitBake使用的信息。在基本級(jí)別上,知道BitBake在計(jì)算依賴關(guān)系時(shí)使用DEPENDS和RDEPENDS變量就足夠了。
有關(guān)BitBake如何處理依賴關(guān)系的更多信息,請參閱“依賴項(xiàng)”部分。
2.6.任務(wù)列表
基于生成的provider列表和依賴信息,BitBake現(xiàn)在可以準(zhǔn)確計(jì)算出需要運(yùn)行的任務(wù)以及按照什么順序運(yùn)行它們。“執(zhí)行任務(wù)”部分有更多關(guān)于BitBake如何選擇接下來要執(zhí)行的任務(wù)的信息。
現(xiàn)在,構(gòu)建以BitBake fork線程開始,最多可以fork的線程數(shù)目由BB_NUMBER_THREADS變量設(shè)置。只要有任務(wù)準(zhǔn)備好運(yùn)行,這些任務(wù)的所有依賴關(guān)系都已滿足,并且線程數(shù)目閾值沒有被超過,BitBake就繼續(xù)fork線程。
值得注意的是,通過正確設(shè)置BB_NUMBER_THREADS變量,可以大大加快編譯時(shí)間。
當(dāng)每個(gè)任務(wù)完成時(shí),時(shí)間戳被寫入由STAMP變量指定的目錄。在后續(xù)運(yùn)行中,BitBake會(huì)在tmp/ stamps內(nèi)的構(gòu)建目錄中查找,并且不會(huì)重新運(yùn)行已完成的任務(wù),除非發(fā)現(xiàn)時(shí)間戳無效。目前,僅在每個(gè)配方文件的基礎(chǔ)上考慮無效的時(shí)間戳。因此,例如,如果配置戳記的時(shí)間戳大于給定目標(biāo)的編譯時(shí)間戳,那么編譯任務(wù)將重新運(yùn)行。但是,再次運(yùn)行編譯任務(wù)對依賴于該目標(biāo)的其他提供程序沒有影響。
時(shí)間戳的確切格式部分是可配置的。在現(xiàn)代版本的BitBake中,hash被附加到stamp上,以便如果配置更改,stamp將變?yōu)闊o效,并且任務(wù)會(huì)自動(dòng)重新運(yùn)行。此hash或使用的簽名由配置的簽名策略管理(有關(guān)信息,請參閱“Checksums(簽名)”部分)。也可以使用[stamp-extra-info]任務(wù)標(biāo)志將額外的元數(shù)據(jù)附加到stamp上。例如,OpenEmbedded使用這個(gè)標(biāo)志來完成一些特定于機(jī)器的任務(wù)。
有些任務(wù)被標(biāo)記為“nostamp”。這些任務(wù)運(yùn)行時(shí)不會(huì)創(chuàng)建時(shí)間戳文件,因此,執(zhí)行構(gòu)建任務(wù)時(shí),“nostamp”總是重新運(yùn)行。
更多詳細(xì)信息,請參閱“Task”章節(jié)描述。
2.7.執(zhí)行任務(wù)
任務(wù)可以是shell或Python任務(wù)。對于shell任務(wù),BitBake將shell腳本寫入$ {T} /run.do_taskname.pid,然后執(zhí)行腳本。生成的shell腳本包含所有導(dǎo)出的變量,并且shell函數(shù)包含所有變量。shell腳本的輸出轉(zhuǎn)到文件$ {T} /log.do_taskname.pid。查看運(yùn)行文件中的擴(kuò)展shell函數(shù)和日志文件中的輸出是一種有用的調(diào)試技術(shù)。
對于Python任務(wù),BitBake在內(nèi)部執(zhí)行任務(wù)并將信息記錄到控制終端。未來版本的BitBake將把函數(shù)寫入類似于shell任務(wù)處理方式的文件中。日志記錄將以類似于shell任務(wù)的方式進(jìn)行處理。
BitBake運(yùn)行任務(wù)的順序由其任務(wù)調(diào)度程序控制。可以配置調(diào)度程序并為特定用例定義自定義實(shí)現(xiàn)。有關(guān)更多信息,請參閱控制行為的這些變量:
- BB_SCHEDULER
- BB_SCHEDULERS
可以在任務(wù)的main函數(shù)之前和之后運(yùn)行某些函數(shù)。這是通過使用列出要運(yùn)行的函數(shù)的任務(wù)的[prefuncs]和[postfuncs]標(biāo)志完成的。
2.8.校驗(yàn)
校驗(yàn)和是任務(wù)輸入的唯一簽名。任務(wù)的簽名可以用來確定任務(wù)是否需要運(yùn)行。因?yàn)槿蝿?wù)輸入的變化觸發(fā)了任務(wù)的運(yùn)行,所以BitBake需要檢測給定任務(wù)的所有輸入。對于shell任務(wù),事實(shí)證明這是相當(dāng)簡單的,因?yàn)锽itBake為每個(gè)任務(wù)生成一個(gè)“運(yùn)行”shell腳本,并且可以創(chuàng)建一個(gè)校驗(yàn)和,讓你很好地了解任務(wù)數(shù)據(jù)的變化。
全面點(diǎn)分析,有些事情不應(yīng)該包含在校驗(yàn)和中。首先,給定任務(wù)的實(shí)際特定構(gòu)建路徑-工作目錄。工作目錄是否改變并不重要,因?yàn)樗粦?yīng)該影響目標(biāo)包的輸出。排除工作目錄的簡單方法是將其設(shè)置為某個(gè)固定值,并為“運(yùn)行”腳本創(chuàng)建校驗(yàn)和。BitBake更進(jìn)一步,使用BB_HASHBASE_WHITELIST變量來定義生成簽名時(shí)不應(yīng)包含的變量列表。
另一個(gè)問題是由包含可能被調(diào)用或可能不被調(diào)用的函數(shù)的“運(yùn)行”腳本產(chǎn)生的。增量構(gòu)建解決方案包含計(jì)算shell函數(shù)之間依賴關(guān)系的代碼。這段代碼被用來修剪“運(yùn)行”腳本到最小集合,從而緩解這個(gè)問題,并使“運(yùn)行”腳本更加可讀。
到目前為止,我們解決shell腳本任務(wù)。那么Python的任務(wù)呢?即使這些任務(wù)比較困難,同樣的方法也適用。該過程需要確定一個(gè)Python函數(shù)訪問什么變量以及它調(diào)用哪些函數(shù)。同樣,增量構(gòu)建解決方案包含首先計(jì)算變量和函數(shù)依賴關(guān)系的代碼,然后為用作輸入任務(wù)的數(shù)據(jù)創(chuàng)建校驗(yàn)和。
像工作目錄一樣,應(yīng)該忽略依賴關(guān)系的情況。對于這些情況,可以通過使用如下所示的行來指示構(gòu)建過程忽略依賴關(guān)系:
PACKAGE_ARCHS[vardepsexclude] = "MACHINE"