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

現特意將這個buildroot的相關文檔上傳上來。

The Buildroot user manual

仔細閱讀這個文檔，許多之前不明白的問題（其實之前也就是沒有搞清楚來龍去脈）現在終于有些眉目了。

2.3節

當用戶執行了make menuconfig（或者make xconfig，make gconfig）設置并保存之后：

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文件！

接下來我們就是執行make命令了，make在背地里做了什么，這個文檔也把它的罪行昭示天下了：

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/ 存放除交叉編譯器之外的所有組件，每個組件自己有一個文件夾
staging/ 包含有一套與根文件系統類似的層級文件目錄，其中包括有交叉編譯器和為目標系統所選的各種包文件，但是這個根目錄不能直接用于目標板上：這些文件包含有大量調試開發文件，二進制文件和庫，對于目標系統來說就太大了
target/ 包含幾乎與目標根文件系統一樣的目錄，尚缺少的是設備文件/dev（Buildroot不是運行在也不想運行在root權限下），因而這個目錄也不能作為目標系統的根文件系統，你應該使用images/下的其中一個作為目標系統的根文件系統
host/ 包含host所需要的各種安裝包（為運行buildroot所需要的各組件，及交叉編譯器）
toolchain/ 里面存放的是適用不同平臺的各個交叉編譯器的編譯目錄

3.3 用戶定制
3.3.1 定制生成的目標文件系統
除了使用make *config的方式之后，用戶還可以通過以下幾種方法來配置目標板的文件系統

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

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

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內核

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 保存配置基礎

3.4.1.1 Buildroot配置

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

與Buildroot一樣，busybox/linux kernel/barebox/uClibc的配置信息也應該及時被保存起來。而對于這些配置文件的讀入，buildroot都有在相應的某個地方可以設置這些文件的路徑。比如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.

請確保在修改BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE等配置前你已經有對應的配置文件了，否則buildroot去訪問該文件又不存在時便出錯。

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.

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。