寫在前面的廢話：工作驅動，Yocto Project拔草，後面有心情就接着翻其他文件
src_url：https://www.yoctoproject.org/docs/3.1.2/bitbake-user-manual/bitbake-user-manual.html

1. 概述

歡迎使用《 BitBake使用者手冊》。本手冊提供有關BitBake工具的資訊。本文資訊儘量獨立於使用BitBake工具的系統，如OpenEmbedded和Yocto Project。在某些情況下，本手冊中使用了構建系統上下文中的場景或範例來幫助理解。對於這些情況，該手冊明確說明了上下文。

1.1 介紹

從根本上講，BitBake是一個通用的任務執行引擎，它允許Shell和Python任務在處理複雜任務間依賴時高效、並行地執行。 BitBake的主要使用者之一OpenEmbedded以此內核爲基礎，並使用面向任務的方法構建嵌入式Linux軟體棧。

從概念上講，BitBake在某些方面類似於GNU Make，但有很大區別：

BitBake根據提供的構建任務的元數據執行任務。元數據儲存在配方（.bb）和相關配方「追加」（.bbappend）檔案，設定（.conf）和基礎包含（.inc）檔案以及類（.bbclass）檔案中。元數據向BitBake提供有關要執行哪些任務以及這些任務之間的依賴關係的說明。
BitBake包含一個提取程式庫，用於從各個地方（例如本地檔案，原始碼控制系統或網站）獲取原始碼。
每個要構建的單元（例如，一個軟體）的指令集合稱爲「配方」檔案，其中包含有關該單元的所有資訊（依賴，原始檔位置，校驗和，描述等）。
BitBake包含用戶端/伺服器抽象，可以從命令列使用，也可以通過XML-RPC用作服務，並且具有多個不同的使用者介面。

1.2 歷史和目標

BitBake最初是OpenEmbedded專案的一部分。它的靈感來自Gentoo Linux發行版使用的Portage軟體包管理系統。 2004年12月7日，OpenEmbedded專案團隊成員Chris Larson將專案分爲兩個不同的部分：

BitBake，通用任務執行器
OpenEmbedded，BitBake使用的元數據集

如今，BitBake已成爲OpenEmbedded專案的主要基礎，該專案被用於構建和維護Angstrom Distribution等Linux發行版，並且還被用作Linux專案（如Yocto Project）的構建工具。

在BitBake之前，沒有其他構建工具可以充分滿足有抱負的嵌入式Linux發行版的需求。傳統桌面Linux發行版使用的所有構建系統都缺少一些重要的功能，並且嵌入式領域中流行的基於Buildroot的專用系統都沒有可伸縮性或可維護性。

BitBake的一些重要的原始目標是：

處理交叉編譯。
處理包之間的依賴關係（編譯時目標架構依賴，編譯時本地架構依賴，執行時依賴）。
對於指定的包，支援在執行任意數量的任務，包括但不限於，獲取上遊原始碼，解壓縮，patch，設定等等。
對於構建系統和目標系統，不限制使用的Linux發行版。
架構無關。
支援多種構建和目標操作系統（例如Cygwin，BSD等）。
獨立包含所有依賴，而不是緊密整合到構建計算機的根檔案系統中。
處理對於目標體系結構，操作系統，發行版和計算機上的條件元數據。
易於使用的工具來提供要操作的本地元數據和程式包。
易於使用BitBake在多個專案之間進行共同作業以進行構建。
提供繼承機制機製，以在許多軟體包之間共用通用元數據。

隨着時間的流逝，顯然還需要一些附加要求：

處理基本配方的變體（例如native，sdk和multilib）。
將元數據分爲多個層，並允許層增強或覆蓋其他層。
允許將任務給定的一組輸入變數表示爲校驗和。根據該校驗和，允許使用預構建的元件加速構建。

BitBake滿足了所有最初的要求，並且通過對基本功能進行了擴充套件以反映附加要求，從而滿足了更多要求。靈活性和強大(power)一直是我們的首要任務。 BitBake具有高度的可延伸性，並支援嵌入式Python程式碼和任意任務的執行。

1.3 概念

BitBake是用Python語言編寫的程式。在最上層邏輯上，BitBake解釋元數據，確定需要執行哪些任務，然後執行這些任務。與GNU Make相似，BitBake控制軟體的構建方式。 GNU Make通過「 makefiles」實現控制，而BitBake使用「 recipes」。

BitBake通過允許定義更復雜的任務，擴充套件了GNU Make這種簡單工具的功能，例如構建整個嵌入式Linux發行版。

本節的其餘部分介紹了一些應理解的概念，以便更好地利用BitBake的功能。

1.3.1 配方(Recipes)

BitBake食譜（以副檔名.bb表示）是最基本的元數據檔案。這些配方檔案爲BitBake提供以下內容：

有關軟體包的描述性資訊（作者，主頁，許可證等）
配方版本
現有依賴關係（構建和執行時依賴關係）
原始碼所在的位置以及如何獲取它
原始碼是否需要任何修補程式，在哪裏可以找到它們以及如何應用它們
如何設定和編譯原始碼
如何將生成的檔案打包到一個或多個可安裝的軟體包中
在目標計算機上的哪個位置安裝軟體包

在BitBake或任何使用BitBake作爲其構建系統的專案的上下文中，擴充套件名爲.bb的檔案稱爲配方(recipes)。

說明：
術語「package」也通常用於描述配方。但是，由於使用相同的詞來描述專案的打包輸出，因此最好保留一個描述性術語-「配方」。換句話說，單個「食譜」檔案完全能夠生成許多相關但可單獨安裝的「package」。實際上，這種能力相當普遍。

1.3.2 組態檔(Configuraion Files)

組態檔以.conf擴充套件名錶示，它們定義了控制專案構建過程的各種設定變數。這些檔案分爲幾個區域，這些區域定義了機器設定(machine configuration)，分發設定(distribution configuration)，可能的編譯器調整，常規通用設定和使用者設定。主要組態檔是範例bitbake.conf檔案，該檔案位於BitBake原始碼樹的conf目錄中。

1.3.3 類(Classes)

用.bbclass擴充套件名錶示的類檔案包含對在元數據檔案之間共用的有用資訊。 BitBake源樹當前帶有一個稱爲base.bbclass的類元數據檔案。您可以在classes目錄中找到此檔案。 base.bbclass類檔案是特殊的，因爲它始終自動包含在所有配方和類中。此類包含用於標準基本任務的定義，例如獲取，解壓縮，設定（預設爲空），編譯（執行存在的任何Makefile），安裝（預設爲空）和打包（預設爲空）。這些任務通常被在專案開發過程中新增的其他類覆蓋或擴充套件。

1.3.4 層(Layers)

層允許您將不同的自定義型別相互隔離。雖然您可能會發現在單個專案中將所有內容都保留在一層中很誘人，但是元數據的模組化程度越高，應對將來的更改就越容易。

爲了說明如何使用層使事物保持模組化，請考慮爲支援特定目標計算機而可能進行的自定義。這些型別的定製通常位於一個特殊的層，而不是一個稱爲「板級支援包（BSP）」層的常規層。此外，應將對機器的自定義與支援新GUI環境的配方和元數據隔離開來。這種情況爲您提供了兩層：一層用於計算機設定，一層用於GUI環境。但是，重要的是要理解，BSP層仍可以在GUI環境層內對配方新增特定於機器的內容，而不會因這些特定於機器的更改而污染GUI層本身。您可以通過作爲BitBake附加（.bbappend）檔案的配方來實現此目的。

1.3.5 附加檔案(Append Files)

附加檔案是具有.bbappend副檔名的檔案，用於擴充套件或覆蓋現有配方檔案中的資訊。

BitBake希望每個附加檔案都具有一個對應的配方檔案。此外，附加檔案和相應的配方檔案必須使用相同的根檔名。檔名只能在使用的檔案型別後綴中有所不同（例如formfactor_0.0.bb和formfactor_0.0.bbappend）。

附加檔案中的資訊擴充套件或覆蓋了基礎名稱相似的配方檔案中的資訊。

爲附加檔案命名時，可以使用「％」萬用字元來匹配配方名稱。例如，假設您有一個名爲如下的附加檔案：

busybox_1.21.％.bbappend

該附加檔案將匹配該食譜的任何busybox_1.21.x.bb版本。因此，附加檔案將與以下配方名稱匹配：

busybox_1.21.1.bb
busybox_1.21.2.bb
busybox_1.21.3.bb

說明：
「％」字元的使用受到限制，因爲它只能直接在附加檔名的.bbappend部分前面使用。您不能在名稱的任何其他位置使用萬用字元。

如果busybox配方已更新爲busybox_1.3.0.bb，則追加名稱將不匹配。但是，如果您將附加檔案命名爲busybox_1.％.bbappend，則可以匹配。
通常，您可以將附加檔案命名爲busybox _％.bbappend之類的簡單名稱，使其完全獨立於版本。

1.4 獲取BitBake

您可以通過幾種不同的方式獲取BitBake：

克隆BitBake：使用Git克隆BitBake原始碼儲存庫是獲得BitBake的推薦方法。克隆儲存庫可以輕鬆獲得錯誤修復，並可以存取穩定的分支和master分支。克隆BitBake後，應使用最新的穩定分支進行開發，因爲主分支用於BitBake開發，並且可能包含一些不穩定修改。
通常，您需要一個與您使用的元數據匹配的BitBake版本。元數據通常向後相容，但不向前相容。
這是克隆BitBake儲存庫的範例：
```
$ git clone git：//git.openembedded.org/bitbake
```
此命令將BitBake Git儲存庫克隆到一個名爲bitbake的目錄中。另外，如果您不想將目錄命名爲bitbake，則可以在git clone命令之後指定目錄。這是一個命名目錄bbdev的範例：
```
$ git clone git：//git.openembedded.org/bitbake bbdev
```
使用包管理系統進行安裝：不建議使用此方法，因爲在大多數情況下，分發所提供的BitBake版本落後BitBake儲存庫快照多個發行版。
獲取BitBake快照：從原始碼儲存庫下載BitBake快照可讓您存取BitBake的已知分支或版本。

說明：
如前所述，克隆Git儲存庫是獲取BitBake的首選方法。克隆儲存庫使將修補程式新增到穩定分支時更容易更新。

以下範例下載BitBake版本1.17.0的快照：
```
$ wget http://git.openembedded.org/bitbake/snapshot/bitbake-1.17.0.tar.gz
$ tar zxpvf bitbake-1.17.0.tar.gz
```
使用您構建系統檢出附帶的BitBake：獲得BitBake副本的最後一種可能性是，它已經隨您檢出的基於BitBake的大型構建系統（例如Poky）一起提供。您可以檢出整個構建系統，而不是手動檢出各個層並將其自己粘在一起。結帳將已經包含經過徹底測試的與其他元件相容性的BitBake版本。有關如何檢出基於BitBake的特定構建系統的資訊，請參閱該構建系統的支援文件。

1.5 BitBake命令

bitbake命令是BitBake工具的主要介面。本節介紹BitBake命令語法，並提供幾個執行範例。

1.5.1 用法和語法

以下是BitBake的用法和語法：

$ 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.
       -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         Enable tracing of shell tasks (with 'set -x'). Also
                             print bb.note(...) messages to stdout (in addition to
                             writing them to ${T}/log.do_<task>).
       -D, --debug           Increase the debug level. You can specify this more
                             than once. -D sets the debug level to 1, where only
                             bb.debug(1, ...) messages are printed to stdout; -DD
                             sets the debug level to 2, where both bb.debug(1, ...)
                             and bb.debug(2, ...) messages are printed; etc.
                             Without -D, no debug messages are printed. Note that
                             -D only affects output to stdout. All debug messages
                             are written to ${T}/log.do_taskname, regardless of the
                             debug level.
       -q, --quiet           Output less log message data to the terminal. You can
                             specify this more than once.
       -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 (knotty, ncurses or taskexp
                             - default knotty).
       --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.
       -B BIND, --bind=BIND  The name/address for the bitbake xmlrpc server to bind
                             to.
       -T SERVER_TIMEOUT, --idle-timeout=SERVER_TIMEOUT
                             Set timeout to unload bitbake server due to
                             inactivity, set to -1 means no unload, default:
                             Environment variable BB_SERVER_TIMEOUT.
       --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 any running bitbake 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.
       --runall=RUNALL       Run the specified task for any recipe in the taskgraph
                             of the specified target (even if it wouldn't otherwise
                             have run).
       --runonly=RUNONLY     Run only the specified task within the taskgraph of
                             the specified targets (and any task dependencies those
                             tasks may have).

1.5.2 範例

本節提供一些範例，展示如何使用BitBake。

1.5.2.1 針對單個配方執行任務

對單個配方檔案執行任務相對簡單。您指定特定檔案，然後BitBake解析該檔案並執行指定的任務。如果您未指定任務，則BitBake將執行預設任務「 build」。

以下命令在foo_1.0.bb配方檔案上執行預設構建任務：

$ bitbake -b foo_1.0.bb

以下命令在foo.bb配方檔案上執行clean任務：

$ bitbake -b foo.bb -c clean

說明：
「 -b」選項顯式指定不處理配方依賴項。除了用於偵錯目的之外，建議您使用下一節介紹的語法。

1.5.2.2 針對一組配方檔案執行任務

當要管理多個.bb檔案時，會引入許多其他複雜性。顯然，需要一種方法來告訴BitBake哪些檔案可用，以及哪些檔案要執行。還需要一種方法來說明構建和執行每個配方時的其依賴性。當多個配方提供相同的功能或一個配方有多個版本時，必須有一種表達配方偏好設定的方法。

當不使用「 --buildfile」或「 -b」時，bitbake命令僅接受「 PROVIDES」。您無法提供其他任何東西。預設情況下，配方檔案通常「PROVIDES」其「packagename」，如以下範例所示：

$ bitbake foo

下一個範例「提供」軟體包名稱，並使用「 -c」選項告訴BitBake僅執行do_clean任務：

$ bitbake -c clean foo

1.5.2.3 執行任務和配方的組合列表

當您指定多個目標時，BitBake命令列支援爲每個單獨目標指定不同的任務。例如，假設您有兩個目標（或配方）myfirstrecipe和mysecondrecipe，並且您需要BitBake爲第一個配方執行taskA和爲第二個配方執行taskB：

$ bitbake myfirstrecipe:do_taskA mysecondrecipe:do_taskB

1.5.2.4 生成依賴圖

BitBake能夠使用dot語法生成依賴關係圖。您可以使用Graphviz中的dot工具將這些圖形轉換爲影象。

生成依賴關係圖時，BitBake將兩個檔案寫入當前工作目錄：

task-depends.dot：顯示任務之間的依賴關係。這些依賴項與BitBake的內部任務執行列表匹配。
pn-buildlist：顯示要構建的目標的簡單列表。

要停止依賴公共依賴，請使用「 -I」依賴選項，BitBake會從圖中省略它們。忽略這些資訊可以生成更具可讀性的圖形。這樣，您可以將繼承類（例如base.bbclass）中的依賴從圖形中刪除。

以下是建立依賴關係圖的兩個範例。第二個範例省略了該圖中OpenEmbedded中常見的內容：

$ bitbake -g foo
$ bitbake -g -Ivirtual/kernel -I eglibc foo

1.5.2.5 執行多設定構建

BitBake能夠使用一個命令構建多個映象或程式包，其中不同的目標需要不同的設定（多個設定構建）。該場景下，每個目標都稱爲「 multiconfig」。
要完成多重設定構建，必須使用構建目錄中的並行組態檔分別定義每個目標的設定。這些multiconfig組態檔的位置是特定的。它們必須位於當前構建目錄中conf的子目錄multiconfig中。以下是兩個單獨目標的範例：
在这里插入图片描述
之所以需要此檔案層次結構，是因爲在解析層之前，不會構造BBPATH變數。因此，除非組態檔位於當前工作目錄中，否則無法將其用作預組態檔。

至少，每個組態檔都必須定義machine以及BitBake用於構建的臨時目錄。建議的做法指示您不要與構建期間覆蓋使用的臨時目錄。

除了每個目標的單獨組態檔外，還必須啓用BitBake執行多個設定構建。通過在local.conf組態檔中設定BBMULTICONFIG變數來實現啓用。例如，假設您在構建目錄中定義了target1和target2的組態檔。 local.conf檔案中的以下語句不僅使BitBake能夠執行多個設定構建，而且還指定了兩個額外的multiconfig：

BBMULTICONFIG =「 target1 target2」

目標組態檔就緒並啓用BitBake來執行多個設定構建後，請使用以下命令形式開始構建：

$ bitbake [mc:multiconfigname] target [[[[mc:multiconfigname:] target] ...]

以下是兩個額外的多重設定的範例：target1和target2：

$ bitbake mc::target mc:target1:target mc:target2:target

1.5.2.6 使能多設定構建依賴

有時，在多設定構建中，目標（多設定）之間可能存在依賴關係。例如，假設爲了構建用於特定體系結構的映象，需要存在另一個構建用於不同架構的根檔案系統。換句話說，第一個多重設定的映像取決於第二個多重設定的根檔案系統。這種依賴關係本質上是，構建一個多重設定的配方中的任務取決於構建多重設定的配方中另一個任務的完成。

要在多設定構建中啓用依賴關係，必須在配方中使用以下語句形式宣告依賴關係：

task_or_package[mcdepends] ="mc:from_multiconfig:to_multiconfig:recipe_name:task_on_which_to_depend"

爲了更好地展示如何使用此語句，請考慮一個範例，該範例具有兩個multiconfigs：target1和target2：

image_task [mcdepends] =「 mc:target1:target2:image2:rootfs_task」

在此範例中，from_multiconfig爲「 target1」，而to_multiconfig爲「 target2」。配方包含image_task的映像所在的任務取決於用於構建image2的rootfs_task的完成，該映像與「 target2」多設定關聯(image依賴於rootfs_task)。

設定此依賴性後，可以使用BitBake命令如下構建「 target1」多設定：

$ bitbake mc:target1:image1

此命令執行爲「 target1」多設定建立image1所需的所有任務。由於存在依賴性，BitBake還將通過rootfs_task執行「 target2」 multiconfig構建。

有一個配方依賴於另一個版本的根檔案系統，似乎沒什麼用。考慮對image1配方中的語句所做的更改：

image_task[mcdepends] =「 mc:target1:target2:image2:image_task」

在這種情況下，BitBake必須爲「 target2」構建建立image2，因爲「 target1」構建依賴於它。

因爲爲多個設定版本啓用了「 target1」和「 target2」，並且它們具有單獨的組態檔，所以BitBake將每個版本的工件放置在各自的臨時版本目錄中。

2. Execution

執行BitBake的主要目的是產生某種輸出，例如單個可安裝的軟體包，內核，sdk，甚至是完整的，用於特定板子的可引導Linux映像，其中包含引導載入程式，內核和根檔案系統。當然，您可以使用使它執行單個任務，編譯單個配方檔案，捕獲或清除數據或僅返回有關執行環境資訊。

本章從頭到尾介紹使用BitBake建立映像時的執行過程。使用以下命令形式啓動執行過程：

$ bitbake target

在執行BitBake之前，應通過在專案的local.conf組態檔中設定BB_NUMBER_THREADS變數來設定構建主機上可用的並行執行緒。
確定構建主機的此值的常用方法是執行以下命令：
$ grep processor /proc/ cpuinfo
此命令返回考慮了超執行緒的處理器數量。因此，具有超執行緒的四核構建主機最有可能顯示八個處理器，這是您將隨後分配給BB_NUMBER_THREADS的值。
可能更簡單的解決方案是某些Linux發行版（例如Debian和Ubuntu）提供ncpus命令。

2.1 解析基礎設定元數據

BitBake要做的第一件事是解析基本設定元數據。基本設定元數據由專案的bblayers.conf檔案（確定BitBake需要識別的層），所有必需的layer.conf檔案（每一層一個）和bitbake.conf組成。數據本身有多種型別：

食譜：有關特定軟體的詳細資訊。
類數據：常見構建資訊的抽象（例如，如何構建Linux內核）。
設定數據：Machine-specific設定，策略決策等。設定數據充當將所有內容系結在一起的粘合劑。

layer.conf檔案用於構造關鍵變數，例如BBPATH和BBFILES。 BBPATH用於分別在conf和classes目錄下搜尋組態檔和類檔案。 BBFILES用於查詢配方和配方附加檔案（.bb和.bbappend）。如果沒有bblayers.conf檔案，則假定使用者直接在環境中設定了BBPATH和BBFILES。

接下來，使用剛構造的BBPATH變數定位bitbake.conf檔案。 bitbake.conf檔案還可以使用include或require指令包括其他組態檔。

在解析組態檔之前，BitBake將檢視某些變數，包括：

BB_ENV_WHITELIST
BB_ENV_EXTRAWHITE
BB_PRESERVE_ENV
BB_ORIGENV
BITBAKE_UI

此列表中的前四個變數與BitBake在任務執行期間如何處理Shell環境變數有關。預設情況下，BitBake清除環境變數並提供對Shell執行環境的嚴格控制。但是，通過使用前四個變數，您可以對任務執行期間shell中BitBake允許使用的環境變數。

基本設定元數據是全域性的，因此會影響所有執行的配方和任務。

BitBake首先在當前工作目錄中搜尋可選的conf/bblayers.conf組態檔。該檔案應包含BBLAYERS變數，該變數是用空格分隔的"BBLAYERS"目錄列表。回想一下，如果BitBake無法找到bblayers.conf檔案，則假定使用者直接在環境中設定了BBPATH和BBFILES變數。

對於此列表中的每個目錄（層），將找到conf/layer.conf檔案，並將其設定爲對應的LAYERDIR變數。想法是這些檔案會自動爲給定的構建目錄正確設定BBPATH和其他變數。

然後，BitBake希望在使用者指定的BBPATH中找到conf/bitbake.conf檔案。該組態檔通常包含用於引入任何其他元數據的指令，例如特定於體系結構，計算機，本地環境等的檔案。

bitbake.conf檔案中僅允許變數定義和include指令。一些變數直接影響BitBake的行爲。這些變數可能是從環境中設定的，具體取決於前面提到的環境變數或在組態檔中設定。

解析組態檔後，BitBake使用其基本的繼承機制機製（通過類檔案）來繼承一些標準類。當遇到負責獲取一個類的繼承指令時，BitBake解析該類。

始終包含base.bbclass檔案。還包括使用INHERIT變數在設定中指定的其他類。BitBake以與組態檔相同的方式在BBPATH中路徑下的classes子目錄中搜尋類檔案。

瞭解執行環境中使用的組態檔和類檔案的一個好方法是執行以下BitBake命令：

$ bitbake -e > mybb.log

檢查mybb.log的頂部將顯示執行環境中使用的許多組態檔和類檔案。

說明
您需要瞭解BitBake如何解析大括號。如果配方在函數中使用右花括號並且字元沒有前導空格，則BitBake會產生解析錯誤。如果在shell函數中使用一對花括號，則不能將封閉的花括號放在行的開頭。
以下是導致BitBake產生解析錯誤的範例：
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
}
按照以下方式編寫recipe可以避免錯誤：
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 查詢並解析配方(Recipes)

在設定階段，BitBake將設定BBFILES。 BitBake現在使用它來構造要解析的配方列表，以及要應用的任何附加檔案（.bbappend）。 BBFILES是可用檔案的空格分隔列表，並支援萬用字元。一個例子是：

BBFILES ="/path/to/bbfiles/*.bb   /path/to/appends/*.bbappend"

BitBake解析每個配方檔案和附加檔案，設定爲變數BBFILES，並將該變數的值儲存到數據儲存中。

說明：
附加檔案按在BBFILES中查詢到的順序應用。

對於每個檔案，都會製作一個基本設定的新副本，然後逐行分析配方。任何inherit語句都會導致BitBake使用BBPATH作爲搜尋路徑來查詢然後解析類檔案(.bbclass)。最後，BitBake按順序分析在BBFILES中找到的所有附加檔案。

一種常見的約定是使用配方檔名定義元數據。例如，在bitbake.conf中，配方名稱和版本用於設定變數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'}"

在此範例中，名爲「 something_1.2.3.bb」的配方會將PN設定爲「 something」，將PV設定爲「 1.2.3」。

到對一個配方(recipe)解析完成時，BitBake擁有該recipe定義的任務列表、由鍵值對組成的數據集以及有關任務的依賴資訊。

BitBake不需要所有這些資訊。只需要一小部分資訊就可以做出有關配方的決定。因此，BitBake快取其感興趣的值，而不儲存其餘資訊。經驗表明，重新解析元數據比嘗試將元數據寫到磁碟然後重新載入要快。

如果可能，後續的BitBake命令將重用此配方資訊的快取。通過首先計算基本設定數據的校驗和（請參閱BB_HASHCONFIG_WHITELIST），然後檢查校驗和是否匹配，來確定此快取的有效性。如果該校驗和與快取中的內容匹配，並且配方和類檔案未更改，則BitBake可以使用快取。然後，BitBake重新載入有關配方的快取資訊，而不是從頭開始重新解析。

配方檔案集合的存在是爲了允許使用者擁有多個包含完全相同軟體包的.bb檔案倉庫。例如，一個人可以很容易地使用它們來製作自己上遊儲存庫的本地副本，但可以進行一些不想要上傳的定製修改。下面下麪是一個例子：

	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"

說明：
現在，分層機制機製是收集程式碼的首選方法。除了收集程式碼之外，該機制機製的主要用途是設定層優先順序並處理層之間的重疊（衝突）。

2.3 Providers

假定已指定BitBake執行目標，並且已解析所有配方檔案，則BitBake開始弄清楚如何構建目標。 BitBake遍歷每個配方的"PROVIDES"列表。"PROVIDES"列表是一個名字列表，通過這些名字配方可以被知道。每個配方的PROVIDES列表都是通過配方的PN變數隱式建立的，或者通過配方的PROVIDES變數（可選的）顯式建立的。

當配方使用PROVIDES時，除了隱式的PN名稱外，可以在一個或多個替代名稱下找到該配方的功能。舉例來說，假設一個名爲keyboard_1.0.bb的食譜包含以下內容：

PROVIDES += "fullkeyboard"

該配方的PROVIDES列表變爲「 keyboard」（隱式）和「 fullkeyboard」（顯式）。因此，可以在兩個不同的名稱下找到keyboard_1.0.bb中的功能。

2.4 Preferences

PROVIDES列表只是解析目標配方的解決方案的一部分。因爲目標可能有多個提供者，所以BitBake需要通過確定提供者的preference來對提供者進行優先順序排序。

目標具有多個提供者的常見範例是「virtual/kernel」，它在每個內核配方的PROVIDES列表中。每臺機器通常使用類似以下機器組態檔中的行來選擇最佳的內核提供者：

PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"

預設的PREFERRED_PROVIDER是與目標名稱相同的提供者。 BitBake遍歷需要構建的每個目標，並解決它們及其依賴項。

由於給定提供者可能存在多個版本，因此瞭解如何選擇提供者變得很複雜。 BitBake預設爲provider的最高版本。使用與Debian相同的方法進行版本比較。您可以使用PREFERRED_VERSION變數來指定特定版本。您可以使用DEFAULT_PREFERENCE變數影響順序。

預設情況下，檔案的偏好設定爲「 0」。如果將DEFAULT_PREFERENCE設定爲「 -1」，則除非明確參照該配方，否則不太可能使用該配方。將DEFAULT_PREFERENCE設定爲「 1」可能會使用該配方。 PREFERRED_VERSION會覆蓋任何DEFAULT_PREFERENCE設定。 DEFAULT_PREFERENCE通常用於標記更新和更多的實驗配方版本，直到它們經過足夠的測試才能纔能被認爲是穩定的。

當給定配方有多個「版本」時，除非另有說明，否則BitBake預設選擇最新版本。如果所討論的配方的DEFAULT_PREFERENCE設定低於其他配方（預設值爲0），則不會選擇該配方。這使維護配方檔案庫的人員可以指定其對預設所選版本的偏好。此外，使用者可以指定他們的首選版本。

如果第一個配方名爲a_1.1.bb，則PN變數將設定爲「 a」，PV變數將設定爲1.1。

因此，如果存在一個名爲a_1.2.bb的配方，則BitBake將預設選擇1.2。但是，如果在BitBake解析的.conf檔案中定義以下變數，則可以更改該選擇傾向：

PREFERRED_VERSION_a = "1.1"

說明：
配方通常會提供兩個版本-穩定的：編號的（和首選的）版本，以及從原始碼儲存庫自動檢出的版本，該版本被認爲是「bleeding edge」，但可以顯式的選擇。
例如，在OpenEmbedded程式碼庫中，有一個用於BusyBox的標準版本食譜檔案，busybox_1.22.1.bb，但是也有一個基於Git的版本，busybox_git.bb，其中明確包含該行
DEFAULT_PREFERENCE =「 -1」
用於確保始終首選帶編號的穩定版本，除非開發人員另有選擇。

2.5 依賴

每個目標BitBake構建都包含多個任務，例如獲取，解壓縮，修補，設定和編譯。爲了在多核系統上獲得最佳效能，BitBake將每個任務視爲具有自己的一組依賴關係的獨立實體。

依賴關係是通過幾個變數定義的。您可以在本手冊末尾的「變數詞彙表」中找到有關BitBake使用的變數的資訊。從根本上講，知道BitBake在計算依賴關係時使用DEPENDS和RDEPENDS變數就足夠了。

有關BitBake如何處理依賴關係的更多資訊，請參見「依賴關係」部分。

2.6 任務列表

現在，基於生成的提供程式列表和依賴項資訊，BitBake可以準確計算它需要執行哪些任務以及以什麼順序執行它們。「執行任務」部分提供了有關BitBake如何選擇下一步執行的任務的更多資訊。

現在，構建從BitBake新建執行緒開始，直到達到BB_NUMBER_THREADS變數中設定的限制。只要有準備好執行的任務，滿足這些任務的所有依賴關係且未超過執行緒閾值的BitBake都會繼續新建執行緒。

值得注意的是，通過正確設定BB_NUMBER_THREADS變數，可以大大加快構建時間。

完成每個任務後，會將時間戳寫入STAMP變數指定的目錄中。在隨後的執行中，BitBake會在tmp / stamps中的build目錄中查詢，並且不會重新執行已經完成的任務，除非發現時間戳無效。當前，僅基於每個配方檔案考慮時間戳是否無效。因此，例如，如果設定標記的時間戳大於給定目標的編譯時間戳，則將重新執行編譯任務。但是，對依賴該目標的其他providers沒有影響。

時間戳的格式部分可配。在現代版本的BitBake中，雜湊會新增到戳記中，因此，如果設定發生更改，戳記將變爲無效，並且任務將自動重新執行。此雜湊或使用的簽名由設定的簽名策略控制（有關資訊，請參見「校驗和（簽名）」部分）。也可以使用[stamp-extra-info]任務標記將額外的元數據新增到stamp。例如，OpenEmbedded使用此標誌使某些任務特定於計算機。

注意
一些任務被標記爲「 nostamp」任務。執行這些任務時，不會建立任何時間戳檔案。因此，「 nostamp」任務始終會重新執行。

2.7 執行任務

任務可以是Shell任務或Python任務。對於shell程式任務，BitBake將shell指令碼寫入$ {T} /run.do_taskname.pid，然後執行該指令碼。生成的shell指令碼包含所有導出的變數，並且shell函數展開了所有變數。 Shell指令碼的輸出寫入檔案$ {T} /log.do_taskname.pid。檢視執行檔案中展開的Shell函數以及日誌檔案中的輸出是一種有效的偵錯技術。

對於Python任務，BitBake在內部執行任務並將資訊記錄到控制終端。將來的BitBake版本將以類似於處理Shell任務的方式把功能寫入檔案。日誌記錄也將以類似於Shell任務的方式進行處理。

BitBake執行任務的順序由其任務排程器控制。排程器支援設定併爲特定用例自定義實現。有關更多資訊，請參見控制行爲的以下變數：

BB_SCHEDULER
BB_SCHEDULERS

可以在任務的主函數之前和之後執行功能。這是通過使用任務的[prefuncs]和[postfuncs]標誌列出要執行的功能來完成的。

2.8 校驗(簽名)

校驗和是任務輸入的唯一簽名。任務的簽名可用於確定是否需要執行任務。因爲是任務輸入中的更改觸發了任務的執行，BitBake需要檢測給定任務的所有輸入。對於Shell任務而言，這相當容易，因爲BitBake爲每個任務生成一個「執行」的Shell指令碼，並且可以建立一個校驗和，以便您更好地瞭解任務數據何時更改。

使問題複雜化的是，校驗和中不應包含某些內容。首先，對於給定任務存在特定的構建路徑，即工作目錄。工作目錄是否更改並不重要，因爲它不會影響目標軟體包的輸出。排除工作目錄的一種簡單方法是將其設定爲某個固定值，併爲「執行」指令碼建立校驗和。 BitBake改進了一步，它使用BB_HASHBASE_WHITELIST變數定義了在生成簽名時不應該包含的變數列表。

另一個問題來自「執行」指令碼，其中包含可能會或可能不會被呼叫的函數。增量構建解決方案中包含一些程式碼，這些程式碼可以理解Shell函數之間的依賴性，可以將「執行」指令碼刪減到最小集，從而緩解了此問題，並使「執行」指令碼的可讀性更好。

到目前爲止，我們已經爲shell指令碼提供瞭解決方案。那麼Python任務呢？即使這些任務更加困難，也可以使用相同的方法。該過程需要弄清楚Python函數存取哪些變數以及呼叫什麼函數。同樣，增量構建解決方案包含的程式碼將首先找出變數和函數的依賴關係，然後爲任務的輸入數據建立校驗和。

類似於工作目錄的情況，也存在依賴關係應被忽略的情況。對於這些情況，您可以使用以下程式碼行指示構建過程忽略依賴項：

PACKAGE_ARCHS [vardepsexclude] =「MACHINE」

此範例確保PACKAGE_ARCHS變數即使參照了MACHINE也不依賴於MACHINE的值。

同樣，在某些情況下，我們需要新增BitBake無法找到的依賴項。您可以通過使用如下一行來完成此操作：

PACKAGE_ARCHS [vardeps] =「MACHINE」

此範例顯式將MACHINE變數新增爲PACKAGE_ARCHS的依賴項。

考慮內聯Python的情況，例如，BitBake無法找出依賴關係。當以偵錯模式執行時（比如使用-DDD），BitBake在發現無法確定依賴關係的內容時會產生輸出。

到目前爲止，本節僅將討論限制在直接輸入任務中。基於直接輸入的資訊在程式碼中稱爲「基本雜湊」。但是，仍然存在任務的間接輸入的問題-已經構建並存在於構建目錄中的事物。特定任務的校驗和（或簽名）需要新增特定任務所依賴的所有任務的雜湊。選擇要新增哪些依賴項是一項策略決策。但是，其效果是生成一個主校驗和，該主校驗和結合了基本雜湊和任務依賴項的雜湊值。

在程式碼級別，可以通過多種方式影響basehash和依賴任務雜湊。在BitBake組態檔中，我們可以爲BitBake提供一些額外的資訊，以幫助其構造basehash。以下語句可以有效地產生全域性變數依賴項，除了那些從未包含在任何校驗和中的變數以外。本範例使用來自OpenEmbedded的變數來幫助說明這一概念：

BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \
         SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \
         USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \
         PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
         CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"

前面的範例排除了工作目錄，該目錄是TMPDIR的一部分。

確定要通過依賴鏈包含哪些依賴任務hash的規則更爲複雜，通常是通過Python函數完成的。 meta/lib/oe/sstatesig.py中的程式碼顯示了兩個範例，並說明了如何在需要時將自己的策略插入系統。該檔案定義了OpenEmbedded-Core使用的兩個基本簽名生成器:「OEBasic"和"OEBasicHash」。預設情況下，BitBake中啓用了一個虛擬的「noop」簽名處理程式。這意味着行爲與以前的版本相同。預設情況下，OE-Core通過bitbake.conf檔案中的以下設定使用「 OEBasicHash」簽名處理程式：

BB_SIGNATURE_HANDLER？=「 OEBasicHash」

「 OEBasicHash」簽名處理程式與「OEBasic」版本相同，但是將任務雜湊新增到stamp檔案。這樣任何元數據更改都會改變任務雜湊，從而自動使任務再次執行。這樣就無需增加PR值，並且對元數據的更改會自動在整個構建過程中體現。

值得說明的是，這些簽名生成器的最終作用是使某些依賴項和雜湊資訊可用於構建。這些資訊包括：

BB_BASEHASH_task-taskname：配方中每個任務的基礎雜湊。
BB_BASEHASH_filename：taskname：每個相關任務的基礎雜湊。
BBHASHDEPS_filename：taskname：每個任務的任務依賴性。
BB_TASKHASH：當前正在執行的任務的雜湊。

值得注意的是，BitBake的「 -S」選項可讓您偵錯BitBake的簽名處理。傳遞給-S的選項允許使用不同的偵錯模式，既可以使用BitBake自己的偵錯功能，也可以使用metadate或signature handle本身定義的偵錯功能。最簡單的傳參是「 none」，這將導致一組簽名資訊被寫到對應於指定目標的STAMPS_DIR中。當前另一個可用的參數是「 printdiff」，它使BitBake嘗試建立它可以匹配的最接近的簽名（例如在狀態快取中），然後對匹配項執行bitbake-diffsigs以確定這兩個stamp樹的stamp和delta的地方。

注意
將來的BitBake版本可能會提供通過其他「 -S」參數觸發的其他簽名處理程式。

2.9 設定場景(setscene)

Setsene進程使BitBake可以處理「預構建」工件。處理和重用這些工件的能力使BitBake不必每次都從頭開始構建某些東西。相反，BitBake可以在可能的情況下使用現有的構建工件。

BitBake需要具有可靠的數據，以指示工件是否相容。上一節中描述的簽名提供了一種表示工件是否相容的理想方式。如果簽名相同，則可以重用物件。

如果可以重用一個物件，那麼問題就變成瞭如何用預先構建的工件替換給定的一個任務或一組任務。 BitBake通過「 setscene」進程解決了該問題。

當要求BitBake構建給定的目標時，在構建任何東西之前，它首先詢問快取的資訊是否可用於其正在構建的任何目標或任何中間目標。如果快取的資訊可用，則BitBake會使用此資訊替代執行主要任務。

BitBake首先呼叫BB_HASHCHECK_FUNCTION變數定義的函數，並列出要構建的任務列表和相應的雜湊值。該函數被設計爲高效執行，並返回它認爲可以獲取工件的任務列表。

接下來，對於返回可能的每個任務，BitBake執行可能的工件所涵蓋的任務setscene任務。 Setscene版本的任務在任務名稱後附加了字串「 _setscene」。因此，例如，名稱爲xxx的任務具有名爲xxx_setscene的setcene任務。 setcene版本任務執行並提供必要工件，且無論成功或失敗都會返回。

如前所述，一個工件可能覆蓋多個任務。例如，如果您已經具有已編譯的二進制檔案，則獲取編譯器毫無意義。爲了解決這個問題，BitBake爲每個成功的setcene任務呼叫BB_SETSCENE_DEPVALID函數，以瞭解是否需要獲取該任務的依賴關係。

最後，在執行所有setscene任務之後，BitBake呼叫BB_SETSCENE_VERIFY_FUNCTION2中列出的函數，並列出BitBake認爲已「covered」的任務列表。然後，元數據可以確保此列表正確，並且可以通知BitBake它要執行特定的任務，而不管setscene結果。

2.10 記錄日誌

除了標準的命令列選項來控制執行時構建的詳細資訊，bitbake還通過BB_LOGCONFIG變數支援使用者定義的Python日誌記錄設定。此變數定義json或yaml日誌記錄設定，這些設定將智慧地合併到預設設定中。使用以下規則合併日誌記錄的設定：

如果頂層key：bitbake_merge設定爲False，則使用者定義的設定將完全替換預設設定。在這種情況下，所有其他規則都將被忽略。
使用者設定必須具有頂層版本，該version必須與預設設定的值匹配。
在handlers，formatters或filters中定義的所有鍵都將被合併到預設設定的相同部分，如果發生衝突，使用者指定的鍵將替換預設鍵。實際上，這意味着如果預設設定和使用者設定都指定了一個名爲myhandler的處理程式，則使用者定義的處理程式將替換預設值。爲防止使用者無意間替換預設handlers，formatters或filters，所有預設處理程式均以字首「BitBake.」命名。
如果使用者將鍵bitbake_merge設定爲False，則logger將完全由使用者設定代替。在這種情況下，沒有其他規則適用於該記錄器。
給定logger的所有使用者定義的filter和handlers屬性都將與預設記錄器的相應屬性合併。例如，如果使用者設定將一個名爲myFilter的過濾器新增到BitBake.SigGen，並且預設設定中新增了一個名爲BitBake.defaultFilter的過濾器，則這兩個過濾器都將應用於logger

例如，請考慮以下使用者日誌記錄組態檔，該檔案將VERBOSE或更高版本的所有與Hash Equivalence相關的訊息記錄到名爲hashequiv.log的檔案中。

{
        "version": 1,
        "handlers": {
            "autobuilderlog": {
                "class": "logging.FileHandler",
                "formatter": "logfileFormatter",
                "level": "DEBUG",
                "filename": "hashequiv.log",
                "mode": "w"
            }
        },
        "formatters": {
                "logfileFormatter": {
                    "format": "%(name)s: %(levelname)s: %(message)s"
                }
        },
        "loggers": {
            "BitBake.SigGen.HashEquiv": {
                "level": "VERBOSE",
                "handlers": ["autobuilderlog"]
            },
            "BitBake.RunQueue.HashEquiv": {
                "level": "VERBOSE",
                "handlers": ["autobuilderlog"]
            }
        }
    }

3. 語法和操作

3.1 基礎語法

3.2 導出變數到環境變數

3.3 條件語法(覆蓋)

3.4 通用功能

3.5 函數

3.6 任務

3.7 變數標誌

3.8 事件

3.9 變體-類擴充套件機制機製

3.10 依賴

3.11 Python中可以呼叫的方法

3.12 任務校驗和和setscene

3.13 變數萬用字元

4. 檔案下載支援

BitBake的獲取模組是一個獨立的程式碼庫，用於處理從遠端系統下載原始碼和檔案的複雜工作。獲取原始碼是構建軟體的基石之一。因此，該模組構成了BitBake的重要組成部分。

當前的提取模組稱爲「 fetch2」，指的是它是該API的第二個主要版本。原始版本已過時，並且已從程式碼庫中刪除。因此，在所有情況下，「 fetch」在本手冊中均指「 fetch2」。

4.1 下載(Fetch)

在獲取原始碼或檔案時，BitBake採取了幾個步驟。提取程式程式碼庫按順序處理兩個不同的過程：從某個地方（快取或其他地方）獲取檔案，然後將這些檔案解壓縮到特定位置，並且可能以特定方式。在獲取和解壓縮檔案後，通常可以選擇是否打修補程式。但是，此部分不涵蓋打修補程式。

執行此過程第一部分的程式碼，即提取，如下所示：

	 src_uri = (d.getVar('SRC_URI') or "").split()
     fetcher = bb.fetch2.Fetch(src_uri, d)
     fetcher.download()

這段程式碼設定了fetch類的範例。該範例使用SRC_URI變數中用空格分隔的URL列表，然後呼叫download方法下載檔案。

通常在fetch類範例化之後跟以下語句：

	 rootdir = l.getVar('WORKDIR')
     fetcher.unpack(rootdir)

此程式碼將下載的檔案解壓縮到WORKDIR指定的檔案中。

說明：
爲了方便起見，這些範例中的命名與OpenEmbedded使用的變數匹配。如果要檢視上面的程式碼，請查閱OpenEmbedded類檔案base.bbclass。

SRC_URI和WORKDIR變數不會寫死到提取程式中，因爲可以使用不同的變數名來呼叫這些提取程式方法。例如，在OpenEmbedded中，共用狀態（sstate）程式碼使用fetch模組來訪存sstate檔案。

呼叫download（）方法時，BitBake嘗試通過按特定搜尋順序查詢原始檔的方式來解析URL：

Pre-mirror Sites：BitBake首先使用pre-mirrors來嘗試查詢原始檔。這些位置是使用PREMIRRORS變數定義的。
Source URI：如果pre-mirrors失敗，則BitBake使用原始URL（例如來自SRC_URI的URL）。
Mirror Sites：如果發生提取失敗，則BitBake接下來將使用MIRRORS變數定義的映象位置。

對於傳遞給提取程式的每個URL，提取程式都會呼叫處理該特定URL型別的子模組。當您爲SRC_URI變數提供URLs時，此行爲可能會引起混亂。考慮以下兩個URL：

http://git.yoctoproject.org/git/poky;protocol=git
git：//git.yoctoproject.org/git/poky; protocol = http

在前一種情況下，URL被傳遞到不瞭解「 git」的wget提取程式。因此，後一種情況是正確的形式，因爲Git提取程式確實知道如何使用HTTP作爲傳輸。

以下是一些顯示常用映象定義的範例：

	PREMIRRORS ?= "\
         bzr://.*/.*   http://somemirror.org/sources/ \n \
         cvs://.*/.*   http://somemirror.org/sources/ \n \
         git://.*/.*   http://somemirror.org/sources/ \n \
         hg://.*/.*    http://somemirror.org/sources/ \n \
         osc://.*/.*   http://somemirror.org/sources/ \n \
         p4://.*/.*    http://somemirror.org/sources/ \n \
         svn://.*/.*   http://somemirror.org/sources/ \n"

     MIRRORS =+ "\
         ftp://.*/.*      http://somemirror.org/sources/ \n \
         http://.*/.*     http://somemirror.org/sources/ \n \
         https://.*/.*    http://somemirror.org/sources/ \n"

值得注意的是BitBake支援跨URL。可以將HTTP伺服器上的Git儲存庫映象爲tarball。就像前面範例中的git:// mapping展示的那樣。

由於網路存取速度很慢，因此BitBake維護從網路下載的檔案的快取。任何非原生的原始檔（即從Internet下載的檔案）都將放置在由DL_DIR變數指定的下載目錄中。

檔案完整性對於可復現的構建至關重要。對於非本地檔案下載，提取程式可以驗證SHA-256和MD5校驗和，以確保檔案已正確下載。您可以通過將SRC_URI變數與相應的varflags一起使用來指定這些校驗和，如下所示：

	 SRC_URI[md5sum] = "value"
     SRC_URI[sha256sum] = "value"

您還可以將校驗和指定爲SRC_URI上的參數，如下所示：

SRC_URI =「 http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d」

如果存在多個URIs，則可以像上一個範例一樣直接指定校驗和，也可以命名這些URLs。以下語法展示瞭如何命名URI：

SRC_URI =「 http://example.com/foobar.tar.bz2;name=foo」
SRC_URI [foo.md5sum] = 4a8e0f237e961fd7785d19d07fdb994d

下載檔案並檢查其校驗和之後，在DL_DIR中放置一個「 .done」標記。 BitBake在後續構建過程中會使用此標記，以避免再次下載或比較檔案的校驗和。

注意
假定本地儲存可以防止數據損壞。如果不是這種情況，將有更大的問題要擔心。

如果設定了BB_STRICT_CHECKSUM，則沒有校驗和的任何下載都會觸發錯誤訊息。 BB_NO_NETWORK變數可用於使任何嘗試的網路存取成爲致命錯誤，這對於檢查映象是否像其他內容一樣完整很有用。

4.2 解壓(Unpack)

下載後通常會立即進行解壓縮。對於除Git URL之外的所有URL，BitBake使用通用的解壓方法。

您可以在URL中指定許多參數來控制解壓縮階段的行爲：

unpack：控制是否對URL元件進行解壓縮。如果設定爲預設值「 1」，則會解壓該元件。如果設定爲「 0」，則解壓縮階段將不處理該檔案。當您要複製歸檔檔案而不將其解壓縮時，此參數很有用。
dos：適用於.zip和.jar檔案，並指定是否對文字檔案使用DOS行尾轉換。
basepath：指示解壓縮階段在解壓縮時從源路徑中剝離指定的目錄。
subdir：將特定的URL解壓縮到根目錄中的指定子目錄。

解壓縮呼叫會自動解壓縮並提取帶有「 .Z」，「.z」，「.gz」，「.xz」，「.zip」，「.jar」，「.ipk」，「.rpm」, 「 .srpm」，「.deb」和「 .bz2」擴充套件名的檔案。

如前所述，Git提取程式具有自己的解壓縮方法，該方法經過優化可與Git樹配合使用。基本上，此方法通過將樹克隆到最終目錄中來工作。該過程使用參照完成，因此只需要一個Git元數據的中央副本。

4.3 抓取器(Fetches)

如前所述，URL字首確定BitBake使用哪個提取程式子模組。每個子模組可以支援不同的URL參數，這將在以下各節中進行介紹。

4.3.1 本地檔案抓取(files://)

該子模組處理以file：//開頭的URL。您在URL中指定的檔名可以是檔案的絕對路徑或相對路徑。如果檔名是相對的，則FILESPATH變數的內容的使用方式與PATH查詢可執行檔案的方式相同。如果找不到該檔案，則假定在呼叫download()方法時由DL_DIR指定。

以下是幾個範例URL，第一個相對URL和第二個絕對URL：

SRC_URI =「 file://relativefile.patch」
SRC_URI =「 file:///Users/ich/very_important_software」

4.3.2 HTTP/FTP的wget抓取(http:// ftp:// https://)

該提取程式從Web和FTP伺服器獲取檔案。在內部，提取程式使用wget實現。

使用的可執行檔案和參數由FETCHCMD_wget變數指定，該變數預設爲合理(sensible)的值。提取程式支援參數「 downloadfilename」，該參數允許指定下載檔案的名稱。指定下載檔案的名稱有助於避免在處理具有相同名稱的多個檔案時DL_DIR中的衝突。

某些範例URL如下：

SRC_URI =「 http://oe.handhelds.org/not_there.aac」
SRC_URI =「 ftp://oe.handhelds.org/not_there_as_well.aac」
SRC_URI =「 ftp：//[email protected]/home/you/secret.plan」

說明：
由於URL參數由分號分隔，因此在解析包含分號的URL時，這可能會引起歧義，例如：
SRC_URI =「 http://abc123.org/git/?p=gcc/gcc.git;a=快照;h = a5dd47」
應該通過用’＆‘字元代替分號來修改此類URL：
SRC_URI =「 http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47」
在大多數情況下，這應該可行。萬維網聯盟（W3C）建議對查詢中的分號和’＆'進行相同處理。請注意，由於URL的性質，您可能還必須指定下載檔案的名稱：
SRC_URI =「 http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47;downloadfilename=myfile.bz2」

4.3.3 CVS抓取(cvs://)

該子模組負責從CVS版本控制系統中檢出檔案。您可以使用許多不同的變數來設定它：

FETCHCMD_cvs：執行cvs命令時要使用的可執行檔案的名稱。該名稱通常是「 cvs」。
SRCDATE：提取CVS原始碼時使用的日期。特殊值「 now」使checkout在每個構建中更新。
CVSDIR：指定儲存臨時checkout的位置。該位置通常是DL_DIR / cvs。
CVS_PROXY_HOST：用作cvs命令的「 proxy =」參數的名稱。
CVS_PROXY_PORT：用作cvs命令的「 proxyport =」參數的埠號。

除了標準的使用者名稱和密碼URL語法外，您還可以使用各種URL參數設定提取程式：
支援的參數如下：

「method」：與CVS伺服器進行通訊的協定。預設情況下，此協定爲「 pserver」。如果將「方法」設定爲「ext」，則BitBake將檢查「 rsh」參數並設定CVS_RSH。對本地目錄，可以使用「 dir」。
「module」：指定要檢出的模組。您必須提供此參數。
「tag」：描述應將哪個CVS TAG用於結帳。預設情況下，TAG爲空。
「date」：指定日期。如果未指定「日期」，則使用設定的SRCDATE簽出特定日期。「 now」的特殊值使checkout在每個構建中更新。
「localdir」：用於重新命名模組。實際上，您將重新命名模組解壓縮到的輸出目錄。您將強制將模組解壓到相對於CVSDIR的指定目錄。
「rsh」：與「 method」參數一起使用。
「scmdata」：設定爲「 keep」時導致CVS元數據在在提取程式建立的壓縮包中得以維護。壓縮包將展開到工作目錄中。預設情況下，將刪除CVS元數據。
「fullpath」：控制結果檢出是在模組級別（預設值）還是在更深的路徑。
「norecurse」：使訪存程式僅檢出指定目錄，而不會遞回到任何子目錄中。
「port」：CVS伺服器連線到的埠。

一些範例URL如下：

     SRC_URI = "cvs://CVSROOT;module=mymodule;tag=some-version;method=ext"
     SRC_URI = "cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat"

4.3.4 SVN抓取(svn://)

該提取程式子模組從Subversion原始碼控制系統中提取程式碼。使用的可執行檔案由FETCHCMD_svn指定，預設爲「 svn」。提取程式的臨時工作目錄由SVNDIR設定，通常爲DL_DIR / svn。

支援的參數如下：

「module」：要簽出的svn模組的名稱。您必須提供此參數。您可以將該參數視爲所需儲存庫數據的頂層目錄。
「path_spec」：用來檢出指定的svn模組的特定目錄。
「protocol」：使用的協定，預設爲「 svn」。如果將「協定」設定爲「 svn + ssh」，則還將使用「 ssh」參數。
「rev」：要簽出的原始碼的修訂版。
「scmdata」：設定爲「 keep」時，導致「.svn」目錄在編譯期間可用。預設情況下，將刪除這些目錄。
「ssh」：當「協定」設定爲「 svn + ssh」時使用的可選參數。您可以使用此參數來指定svn使用的ssh程式。
「transportuser」：必要時，設定傳輸的使用者名稱。預設情況下，此參數爲空。傳輸使用者名稱不同於傳遞給subversion命令的主URL中使用的使用者名稱。

以下是使用svn的三個範例：

SRC_URI =「 svn：// myrepos / proj1; module = vip; protocol = http; rev = 667」
SRC_URI =「 svn：// myrepos / proj1; module = opie; protocol = svn + ssh」
SRC_URI =「 svn：// myrepos / proj1; module = trunk; protocol = http; path_spec = $ {MY_DIR} / proj1」

4.3.5 Git抓取(git://)

該提取程式子模組從Git原始碼控制系統提取程式碼。提取程式通過將遠端程式碼庫裸克隆到GITDIR（通常爲DL_DIR / git2）來工作。然後，在checkout特定樹時，在解壓縮階段將此程式碼庫克隆到工作目錄中。這是通過使用備用方法（通過參照）來完成的，以最大程度地減少磁碟上的重複數據量並加快解壓縮過程。可以使用FETCHCMD_git設定所使用的可執行檔案。

此提取程式支援以下參數：

「protocol」：用於提取檔案的協定。設定主機名時，預設值爲「 git」。如果未設定主機名，則Git協定爲「檔案」。您也可以使用「 http」，「 https」，「 ssh」和「 rsync」。
「nocheckout」：告訴提取器在設定爲「 1」時解包時不檢出原始碼。在存在自定義例程以檢出程式碼的URL上設定此選項。預設值爲「 0」。
「rebaseable」：表示上遊Git儲存庫可以rebase。如果修訂版本可能與分支分離，則應將此參數設定爲「 1」。在這種情況下，每次修訂都會完成源映象壓縮包，這會降低效率。重新建立上遊Git儲存庫的基準可能導致當前修訂版從上遊儲存庫中消失。此選項提醒提取程式仔細保留本地快取以備將來使用。該參數的預設值爲「 0」。
「nobranch」：告訴提取器在設定爲「 1」時不檢查分支的SHA驗證。預設值爲「 0」。爲配方指定此選項，該配方指的是對標籤（而不是分支）有效的提交。
「bareclone」：告訴提取程式裸克隆到目標目錄中，而不checkout工作樹。僅提供原始Git元數據。此參數也暗含「nocheckout」參數。
「branch」：要克隆的Git樹的分支。如果未設定，則預設爲「master」。分支參數的數量與名稱參數的數量必須匹配。
「rev」：用於指定checkout的修訂版本。預設值爲「master」。
「tag」：指定用於檢出的標籤。要正確解析標籤，BitBake必須存取網路。因此，通常不使用標籤。就Git而言，「 tag」參數的行爲實際上與「rev」參數相同。
「subpath」：將檢出限製爲樹的特定子路徑。預設情況下，整個樹都被檢出。
「destsuffix」：放置檢出檔案的路徑的名稱。預設情況下，路徑爲git /。
「usehead」：使本地git：// URL可以將當前分支HEAD用作與AUTOREV一起使用的修訂版。「 usehead」參數表示無分支，僅在傳輸協定爲file：//時有效。

以下是一些範例URL：

SRC_URI =「 git：//git.oe.handhelds.org/git/vip.git; tag = version-1」
SRC_URI =「 git：//git.oe.handhelds.org/git/vip.git; protocol = http」

4.3.6 Git子模組抓取(gitsm://)

此提取程式子模組繼承自Git提取程式(git fetcher)，並通過訪存程式碼庫的子模組擴充套件了提取程式的功能。如4.3.5部分中所述，將SRC_URI傳遞到Git Fetcher。

注意和警告
在「 git：//」和「 gitsm：//」 URL之間切換時，必須清理配方。
Git子模組提取程式不是完整的提取程式實現。提取程式在未正確使用常規源映象基礎結構的地方存在已知問題。此外，許可和源歸檔基礎結構看不到它獲取的子模組源。

4.3.7 ClearCase抓取(ccrc://)

此抓取程式子模組從ClearCase儲存庫中獲取程式碼。

要使用此提取程式，請確保您的配方具有正確的SRC_URI，SRCREV和PV設定。如：

     SRC_URI = "ccrc://cc.example.org/ccrc;vob=/example_vob;module=/example_module"
     SRCREV = "EXAMPLE_CLEARCASE_TAG"
     PV = "${@d.getVar("SRCREV", False).replace("/", "+")}"

提取程式使用rcleartool或cleartool遠端用戶端，具體取決於可用的用戶端。

以下是SRC_URI語句的選項：

vob：ClearCase VOB的名稱，必須包含前置的「 /」字元。此選項是必需的。
module：所選VOB中的模組，必須包含前置的「 /」字元。

注意
模組和VOB選項組合在一起，以在檢視設定規範中建立載入規則。例如，請考慮本節開頭的SRC_URI語句中的vob和module值。合併這些值將得到以下結果：
`load /example_vob/example_module·
proto：協定，可以是http或https。

預設情況下，提取程式建立一個設定規範。如果要將此規範寫入預設區域以外的區域，請在配方中使用CCASE_CUSTOM_CONFIG_SPEC變數來定義規範的寫入位置。

注意
如果指定此變數，SRCREV將失去其功能。但是，即使提取未定義SRCREV，SRCREV仍用於在提取後標記存檔。

以下是一些值得一提的其他行爲：

使用cleartool時，cleartool的登錄由系統處理。登錄無需任何特殊步驟。
爲了將rcleartool與經過身份驗證的使用者一起使用，在使用訪存程式之前，必須先進行「 rcleartool登錄」。

4.3.8 Perforce抓取(p4://)

該提取程式子模組從Perforce原始碼控制系統中提取程式碼。使用的可執行檔案由FETCHCMD_p4指定，預設爲「 p4」。提取程式的臨時工作目錄由P4DIR設定，預設爲「DL_DIR/p4」。

要使用此提取程式，請確保您的配方具有正確的SRC_URI，SRCREV和PV值。如果您不希望在配方本身中保留這些值，則p4可執行檔案可以使用系統的P4CONFIG環境變數定義的組態檔來定義Perforce伺服器URL和埠，使用者名稱和密碼。如果選擇不使用P4CONFIG或顯式設定P4CONFIG可以包含的變數，則可以指定P4PORT值（即伺服器的URL和埠號），並且可以直接在配方中的SRC_URI中指定使用者名稱和密碼。

以下是一個依賴P4CONFIG來指定伺服器URL和埠，使用者名稱和密碼並獲取Head版本的範例：

SRC_URI = "p4://example-depot/main/source/..."
SRCREV = "${AUTOREV}"
PV = "p4-${SRCPV}"
S = "${WORKDIR}/p4"

以下是一個指定伺服器URL和埠，使用者名稱和密碼，並根據標籤獲取修訂的範例：

    P4PORT = "tcp:p4server.example.net:1666"
    SRC_URI = "p4://user:passwd@example-depot/main/source/..."
    SRCREV = "release-1.0"
    PV = "p4-${SRCPV}"
    S = "${WORKDIR}/p4"

注意：
在配方中，應始終將S設定爲「 $ {WORKDIR} / p4」。

4.3.9 Repo抓取(repo://)

此提取程式子模組從google-repo原始碼控制系統中提取程式碼。提取程式通過將程式碼庫初始化並同步到REPODIR（通常爲DL_DIR/repo）中來工作。