Add Packages to System

Buildroot裡面的套件(packages)[以下都稱package]是一系列的meta-information, 這些資訊都是在建制的過程中會被自動建制的，不管是user space, firmware, kernel drivers或是bootloader都包含在這個範疇之內。其中包含幾個部份：

資料夾位置：
假設我們有一個package叫做foo，這個package的meta資料都會放在package/foo底下。
Config.in:
這個檔案是用kconfig語言寫的，描述這個package的組態。
< pkg>.mk:
這個檔案是用make語法寫的，描述到哪裡去取得原始碼，如何建制和如何安裝等等。
< pkg>.hash:
如果這個package是個tarball，則這個hash table就會在下載完以後會去檢查package的完整性。
patch:
在建制專案之前會去套用這個patch檔案。

- Config.in

就如同上面說的，Config.in這個檔案是用kconfig寫的，主要是在描述這個package的組態

舉個例子來說：

config BR2_PACKAGE_STRACE
    bool "strace"
    help
    A useful diagnostic, instructional, and debugging tool.
    Allows you to track what system calls a program makes
    while it is running.

    http://sourceforge.net/projects/strace/

一開始必須命名成：

BR2_PACKAGE_< PACKAGE>

而主要的選項是bool "package name"，這個選項會被menuconfigure所看到。 help是主要描述，還有最底下的是這個專案的網址。

這些『package/< pkg>/Config.in』的檔案都被包含在『package/Config.in』裡面，簡而言之就是你要用到的package路徑都要包含在『package/Config.in』裡面。

- 相依性

kconfig允許『select』或是『depends on』這兩種方式來描述相依性，但是他們只確保在組態(configuration)等級的一致性(consistency)，不代表建制的順序：

『select』，會自動去設定相依性，如果option A select option B，只要A啟動了，則B才會啟動，並且就無法取消select。在buildroot裡面，select用來描述建制這個套件之前，所必要的套件。

『depends on』，則必須自己設定相依性，如果option A depends on option B，則只有在B啟動了，A才會被看到。在buildrood裡面，depends on主要用在架構(architecture), toolchain feature或者是比較大的功能相依性。舉例來說，描述package A只有在x86環境底下才是可視的。

舉個例子來說：上面這個套件，『depends on BR2USE_MMU』，因為這個套件會使用到fork()。『depends on BR2_USE_WCHAR』和『depends on BR2_TOOLCHAIN_HAS_THREADS』則是需要wide-char和thread。至於多個『select BR2_PACKAGE*』則是代表需要多個函式庫的支援。

- kconfig的限制

kconfig也有他的限制在，像是『depends on』並沒有辦法繼承『select』的相依性。舉個例子來說，如果package A depends on Foo, 並且package B select A，則package B就必須變形成depends on Foo。

- Config.in.host

對於大部分的Package來說，幾乎都是『target package』(就是這個套件是為了跑在目標平台，而經過cross-compiled)。但是有些套件卻是要在主機(host)端執行的，就是在其他的package的建制過程會用到這些host package。而這些host package在menuconfig是不可視的，使用者也非一定要知道這些套件。

這些所謂的host package的組態檔都會在『Config.in.host』裡面，跟Config.in一樣，最上層則是在『package/Config.in.host』裡面，而選項的名稱必須是『BR2PACKAGE_HOST< PACKAGE>』。