之前有寫一篇文章：http://www.cnblogs.com/tfanalysis/p/3625430.html理清如何make menuconfig的問題，現(xiàn)在今天在無(wú)意間多注意了一下buildroot這個(gè)工具，發(fā)現(xiàn)編譯openwrt與之有極大的聯(lián)系，或許openwrt就是建立在這個(gè)工具之上的。

現(xiàn)特意將這個(gè)buildroot的相關(guān)文檔上傳上來(lái)。

The Buildroot user manual

仔細(xì)閱讀這個(gè)文檔，許多之前不明白的問題（其實(shí)之前也就是沒有搞清楚來(lái)龍去脈）現(xiàn)在終于有些眉目了。

2.3節(jié)

當(dāng)用戶執(zhí)行了make menuconfig（或者make xconfig，make gconfig）設(shè)置并保存之后：

Once everything is configured, the configuration tool generates a .config file that contains the description of your configura-
tion. It will be used by the Makefiles to do what’s needed.

下面就是剛剛生成的.config文件！

接下來(lái)我們就是執(zhí)行make命令了，make在背地里做了什么，這個(gè)文檔也把它的罪行昭示天下了：

Let’s go:
$ make
You should never use make -jN with Buildroot: it does not support top-level parallel make. Instead, use the BR2_JLEVEL option to tell Buildroot to run each package compilation with make -jN.
The make command will generally perform the following steps:
? download source files (as required);
? configure, build and install the cross-compiling toolchain using the appropriate toolchain backend, or simply import an external toolchain;
? build/install selected target packages;
? build a kernel image, if selected;
? build a bootloader image, if selected;
? create a root filesystem in selected formats.

Buildroo的編譯輸出存放在output/.下面，里頭包含有的文件夾及其用處：

images/ 存放了kernel image, bootloader and root filesystem等images
build/ 存放除交叉編譯器之外的所有組件，每個(gè)組件自己有一個(gè)文件夾
staging/ 包含有一套與根文件系統(tǒng)類似的層級(jí)文件目錄，其中包括有交叉編譯器和為目標(biāo)系統(tǒng)所選的各種包文件，但是這個(gè)根目錄不能直接用于目標(biāo)板上：這些文件包含有大量調(diào)試開發(fā)文件，二進(jìn)制文件和庫(kù)，對(duì)于目標(biāo)系統(tǒng)來(lái)說就太大了
target/ 包含幾乎與目標(biāo)根文件系統(tǒng)一樣的目錄，尚缺少的是設(shè)備文件/dev（Buildroot不是運(yùn)行在也不想運(yùn)行在root權(quán)限下），因而這個(gè)目錄也不能作為目標(biāo)系統(tǒng)的根文件系統(tǒng)，你應(yīng)該使用images/下的其中一個(gè)作為目標(biāo)系統(tǒng)的根文件系統(tǒng)
host/ 包含host所需要的各種安裝包（為運(yùn)行buildroot所需要的各組件，及交叉編譯器）
toolchain/ 里面存放的是適用不同平臺(tái)的各個(gè)交叉編譯器的編譯目錄

3.3 用戶定制
3.3.1 定制生成的目標(biāo)文件系統(tǒng)
除了使用make *config的方式之后，用戶還可以通過以下幾種方法來(lái)配置目標(biāo)板的文件系統(tǒng)

直接修改目標(biāo)文件系統(tǒng)然后再編譯鏡像。這些目標(biāo)文件系統(tǒng)就存在于output/target/.中，你可以直接修改這些文件，然后執(zhí)行make命令編譯——就會(huì)重新編譯目標(biāo)文件系統(tǒng)鏡像。利用這種方法你可以任何修改你的目標(biāo)文件系統(tǒng)，但是需要注意的是，如果你重新編譯了交叉工具鏈和其它工具，那么對(duì)out/target/的修改就會(huì)被覆蓋掉。因而這個(gè)解決方案僅適用于快速測(cè)試，一旦你make clean了你得重新來(lái)過一遍對(duì)output/target/的修改。一旦你已經(jīng)確認(rèn)你的對(duì)目標(biāo)文件系統(tǒng)的修改是正確了的話，那么你需要在你make clean了之后這樣的修改一直保持更新（手動(dòng)），不過通過下面的方法可以自動(dòng)地保持住這些修改；
新建一個(gè)臨時(shí)文件系統(tǒng)：新建一個(gè)目錄樹，當(dāng)你的目標(biāo)文件系統(tǒng)編譯完成之后直接復(fù)制并覆蓋之。只需要把BR2_ROOTFS_OVERLAY設(shè)置為該目錄樹的根目錄就可以了。.git, .svn, .hg directories, .empty files and files ending with ~ are excluded. Among these first 3 methods, this one should be preferred
在buildroot配置項(xiàng)中，你可以指定一個(gè)或多個(gè)post-build scripts。在Buildroot編譯了所有用戶所選的包之后，在組合為根文件系統(tǒng)之前，這些scripts會(huì)按用戶列舉的順序依次執(zhí)行。用戶可通過設(shè)置BR2_ROOTFS_POST_BUILD_SCRIPT的值指定這些腳本所在的具體位置及名字，這個(gè)字段可以在System configuration菜單中找到。Buildroot會(huì)將目標(biāo)根文件系統(tǒng)的目錄作為腳本的第1參數(shù)傳遞過去，因而這些腳本就可以增刪修改該文件系統(tǒng)了。如果你發(fā)現(xiàn)某個(gè)包會(huì)生成你不需要的文件，那么，雖然這些腳本是可以刪除根文件系統(tǒng)中的文件的（清理工作），但是你應(yīng)該去修改這些包上的錯(cuò)誤，而不是使用scripts來(lái)做這樣的善后。另外，在這些scipts中你可以使用下面這些變量：

BR2_CONFIG: the path to the Buildroot .config file
HOST_DIR, STAGING_DIR, TARGET_DIR: see Section 7.2.4.2
BUILD_DIR: the directory where packages are extracted and built
BINARIES_DIR: the place where all binary files (aka images) are stored
BASE_DIR: the base output directory

新建自己的目標(biāo)skeleton（骨架）：你可以參考system/skeleton來(lái)做一個(gè)適用于自己項(xiàng)目的目錄，設(shè)置好BR2_ROOTFS_SKELETON_CUSTOM 和BR2_ROOTFS_SKELETON_CUSTOM_PATH（這些字段可以在System configuration菜單中找到）之后就可以了。編譯過程中，在所有包安裝之后這些骨架內(nèi)容就會(huì)直接拷貝到output/target中了。由于這會(huì)造成系統(tǒng)中帶有兩份skeleton內(nèi)容，不容易將來(lái)對(duì)Buildroot的維護(hù)與升級(jí)，所以這是不推薦的做法。最好的方法還是使用post-build scirpts這個(gè)。

Note also that you can use the post-image scripts if you want to perform some specific actions after all filesystem images have been created (for example to automatically extract your root filesystem tarball in a location exported by your NFS server, or to create a special firmware image that bundles your root filesystem and kernel image, or any other custom action), you can specify a space-separated list of scripts in the BR2_ROOTFS_POST_IMAGE_SCRIPT configuration option. This option can be found in the System configuration menu as well.

Each of those scripts will be called with the path to the images output directory as first argument, and will be executed with the main Buildroot source directory as the current directory. Those scripts will be executed as the user that executes Buildroot, which should normally not be the root user. Therefore, any action requiring root permissions in one of these post-image scripts will require special handling (usage of fakeroot or sudo), which is left to the script developer.

Just like for the post-build scripts mentioned above, you also have access to the following environment variables from your post-image scripts: BR2_CONFIG, BUILD_DIR, HOST_DIR, STAGING_DIR, TARGET_DIR, BINARIES_DIR and BASE_DIR.

Additionally, each of the BR2_ROOTFS_POST_BUILD_SCRIPT and BR2_ROOTFS_POST_IMAGE_SCRIPT scripts will be passed the arguments specified in BR2_ROOTFS_POST_SCRIPT_ARGS (if that is not empty). All the scripts will be passed the exact same set of arguments, it is not possible to pass different sets of arguments to each script.

3.3.2 定制busybox

Busybox is very configurable, and you may want to customize it. You can follow these simple steps to do so. This method isn’t optimal, but it’s simple, and it works:
? Do an initial compilation of Buildroot, with busybox, without trying to customize it.
? Invoke make busybox-menuconfig. The nice configuration tool appears, and you can customize everything.
? Run the compilation of Buildroot again.
Otherwise, you can simply change the package/busybox/busybox-<version>.config file, if you know the options you want to change, without using the configuration tool.
If you want to use an existing config file for busybox, then see Section 3.5.5.

3.3.3 定制uClibc

Just like BusyBox Section 3.3.2, uClibc offers a lot of configuration options. They allow you to select various functionalities depending on your needs and limitations.
The easiest way to modify the configuration of uClibc is to follow these steps:
? Do an initial compilation of Buildroot without trying to customize uClibc.
? Invoke make uclibc-menuconfig. The nice configuration assistant, similar to the one used in the Linux kernel or Buildroot, appears. Make your configuration changes as appropriate.
? Copy the $(O)/build/uClibc-VERSION/.config file to a different place (e.g. board/MANUFACTURER/BOARDNAME/uClibc.config) and adjust the uClibc configuration file option BR2_UCLIBC_CONFIG to refer to this configuration instead of the default one.
? Run the compilation of Buildroot again.
Otherwise, you can simply change package/uclibc/uClibc-VERSION.config, without running the configuration assistant.
If you want to use an existing config file for uClibc, then see Section 3.5.5.

3.3.4 定制Linux內(nèi)核

The Linux kernel configuration can be customized just like BusyBox Section 3.3.2 and uClibc Section 3.3.3 using make linux-menuconfig. Make sure you have enabled the kernel build in make menuconfig first. Once done, run make to (re)build everything.
If you want to use an existing config file for Linux, then see Section 3.5.5.

3.3.5 定制toolchain

3.3.5.2 Using the internal Buildroot toolchain backend
The internal Buildroot toolchain backend allows to generate toolchains based on uClibc, glibc and eglibc. Generation of (e)glibc-based toolchains is still experimental in Buildroot.
It allows to tune major settings, such as:
? Linux headers version;
? C library configuration (only available for uClibc, see uClibc Section 3.3.3);
? Binutils, GCC, Gdb and toolchain options.
These settings are available after selecting the Buildroot toolchain type in the menu Toolchain.

3.4 保存配置

3.4.1 保存配置基礎(chǔ)

3.4.1.1 Buildroot配置

Buildroot提供make savedefconfig這個(gè)命令來(lái)保存自身的配置信息（僅會(huì)存放配置的信息，其余#形狀的選項(xiàng)會(huì)直接去除）。結(jié)果會(huì)在根目錄下生成一個(gè)叫做defconfig的文件，通過修改BR2_DEFCONFIG的值Buildroot會(huì)把defconfig文件寫到該BR2_DEFCONFIG值指定的目錄下去，抑或可以在執(zhí)行make savedefconfig BR2_DEFCONFIG=<path-to-defconfig>指定存放目錄。在menuconfig菜單的Build Options中可以設(shè)置。一般來(lái)說這個(gè)目錄是configs/<boardname>_defconfig，重新編譯時(shí)只要輸入make <boardname>_defconfig就可以了。當(dāng)然，如果你使用了其它BR2_DEFCONFIG目錄的話，重新編譯時(shí)應(yīng)該使用make defconfig BR2_DEFCONFIG=<path-to-defconfig-file>
3.4.1.2 其它包配置

與Buildroot一樣，busybox/linux kernel/barebox/uClibc的配置信息也應(yīng)該及時(shí)被保存起來(lái)。而對(duì)于這些配置文件的讀入，buildroot都有在相應(yīng)的某個(gè)地方可以設(shè)置這些文件的路徑。比如BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE。To save their configuration, set those configuration options to a path outside your output directory, e.g. board/<manufacturer>/<boardname>/linux.config. Then, copy the configuration files to that path.

請(qǐng)確保在修改BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE等配置前你已經(jīng)有對(duì)應(yīng)的配置文件了，否則buildroot去訪問該文件又不存在時(shí)便出錯(cuò)。

You can create the configuration file by running make linux-menuconfig etc.

Buildroot provides a few helper targets to make the saving of configuration files easier.

make linux-update-defconfig saves the linux configuration to the path specified by BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE. It simplifies the config file by removing default values. However, this only works with kernels starting from 2.6.33. For earlier kernels, use make linux-update-config.
make busybox-update-config saves the busybox configuration to the path specified by BR2_PACKAGE_BUSYBOX_CONFIG.
make uclibc-update-config saves the uClibc configuration to the path specified by BR2_UCLIBC_CONFIG.
make barebox-update-defconfig saves the barebox configuration to the path specified by BR2_TARGET_BAREBOX_CUSTOM_CONFIG_FILE.
For at91bootstrap3, no helper exists so you have to copy the config
file manually to BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_CONFIG_FILE.

總結(jié)

以上是生活随笔為你收集整理的Buildroot阅读笔记的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。