Config.in

就像之前說的，每個套件的組態和meta data，都會在每個套件底下的『config.in』，都是用kconfig語言所撰寫的，而啟用這個套件的開關，都必須要以格式『BR2_PACKAGE_<PACKAGE>』來命名。

每個套件的『config.in』的位置，都應該還需要被包含在另一個『config.in』裡面，這個檔案統一會在『buildroot/package/Config.in』，這邊一定要定義，不然menuconfig會抓不到這個設定。

簡單來說『buildroot/package/<pkg>/Config.in』會被包含在『buildroot/package/Config.in』裡面。

舉個例子來說明比較好理解，以套件『XZ』來說，用指令『make menuconfig』打開configuration menu如下:

到路徑『Target packages ---> Compressors and decpmpressors --->』底下，會看到如下設定:

可以看到一個『xz_utils』，這個設定主要是讀取『buildroot/package/Config.in』裡面的:

可以看到『buildroot/package/Config.in』又讀取『buildroot/package/xz/Config.in』如下:

這時候你就看到很熟悉的『xz-tuils』還有底下的描述文字，這不是出現在剛剛menu config上的資訊嗎。更進階的資訊，按一下下面的help以後出現如下，這邊最主要的其他描述資訊是相依性，這邊待回會講解:

然後我們按一下空白鍵來啟動『xz-tuils』這個選項，然後跳出menuconfig，用編輯器打開『.config』，你會發現有個開關『BR2_PACKAGE_XZ』已經被打開了

Dependency

如果在建制一個套件之前，還需要先建制另外一個套件，這種相依性就需要在Config.in裡面使用kconfig的『select』和『depends on』來描述清楚，這邊特別注意這些相依性只是組態的相依性，跟建制的順序沒關係。

select

這個選項是一個相依性的自動選擇，如果A select B的話，一旦A被啟動了，B也會馬上被啟動，而且B並不可以單獨被取消，意思是兩個一定要一起啟動，或是兩個一定要一起取消的意思。在build裡面，通常是用來啟動其他相依性的套件或函式庫。

depends on

這是一個使用者輔助的相依性，如果A depends on B的話，只有在B被啟動的狀況之下，A才會被看到。通常這種相依性被用在buildroot都是用來在一些架構，toolchain功能，或者是比較大的功能的相依性。eg. 如果這個套件只能在x86上面跑，或者是只允許wide char支援的話才能允許選擇。

舉個例子來說：

(來源 : free-electrons )

上面這個套件，『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

對於大部分的套件來說，幾乎都是『target package』(就是套件經過cross-compiled，然後將其移到target board上跑)。但是有些套件卻是要在主機(host)端執行的，意思是就是在其他的套件的建制過程會用到這些host package，官方想要固定住這些host套件的版本，因為這幾個版本的搭配是官方測試過的，這些『host package』在menuconfig是不可視的，使用者也非一定要知道這些套件。
這些所謂的host package的組態檔都會在『Config.in.host』裡面，跟Config.in一樣，最上層則是在『package/Config.in.host』裡面，而選項的名稱必須是『BR2PACKAGE_HOST< PACKAGE>』。