去如下網站下載一個工具包就OK了，o(∩_∩)o...哈哈，過程很簡單了
下載一個buildroot,這是個工具集,接下來所要做的事情就是把gcc、binutils等文件下載下來，放在buildroot下的dl目錄下
（如果沒有這個目錄就自己創建一個就OK了）
當然，你也可以讓buildroot自動下載，MAKE的時候會自動解析DL目錄下的文件，不過速度較慢。
選擇目標的爲MIPS，以及一些工具的版本，順利的話，你編譯完後就能得到MIPS的gcc交叉編譯器了。
還包括文件系統(busybox)，n多的可選應用程序(sqlite等)。
果真好東西，是初學者的福音，推薦。
相關內容請參照一下解釋。
http://buildroot.uclibc.org/README
http://buildroot.uclibc.org/buildroot.html
Buildroot的用法和文檔由Thomas Petazzoni提供，文稿由Karsten Kruse、Ned Ludd、Martin Herren等整理。
最後修改時間：2007-09-19 02:08:10 -0700 (Wed, 19 Sep 2007)
l 關於Buildroot
l 獲取Buildroot
l 使用Buildroot
l 定製目標文件系統
l 定製Busybox的配置
l 定製uClibc的配置
l Buildroot運行方式
l 使用uClibc 工具鏈
l 在Buildroot外部使用 uClibc 工具鏈
l 被下載包的存放位置
l 使用其他軟件來擴展Buildroot
l 資源
關於Buildroot
Buildroot是一個Makefiles和patches的命令集，它可以非常簡單的爲你的目標系統產生一個交叉編譯工具鏈和根文件系統 。這個交叉編譯工具使用uClibc (http://www.uclibc.org/)，uClibc是一個很小的標準庫。
Buildroot那些從事於嵌入式系統的人來說是很有用處的。嵌入式系統經常使用的處理器都不是平常用於普通電腦的x86處理器它可能是PowerPC、 MIPS、ARM等處理器.
一個編譯工具鏈就是一些工具的的命令集，這些工具允許你爲你的目標系統編譯源代碼。它主要由編譯器（在我們的例子中爲gcc），二進制的工具集，如彙編程序和連接器（在我們的例子中爲binutils），還有就是C的標準庫（如GNU Libc、uClibc或者是dietlibc）。在你的開發平臺上安裝的系統裏面要包含一個編譯工具鏈，這個編譯工具鏈是你可以在你的系統上編譯應用程序。如果你使用的是一臺PC機，你的編譯工具鏈運行在x86處理器上，或者生成x86處理器可以運行的代碼。在大多數的Linux系統裏面，這個編譯工具鏈使用的是GNU libc作爲C的標準庫。這個編譯工具鏈被稱之爲“主機編譯工具鏈”，而且通常來說，這臺你在上面工作的電腦被稱之爲“主機系統”。這個編譯工具鏈由你的系統提供，與Buildroot無關。
如同上面所說的一樣，這個編譯工具鏈隨着你操作系統一起爲你的主機系統上的處理器運行或者生成源代碼。就像你的嵌入式系統擁有一個不同的處理器一樣，你需要一個交叉編譯工具鏈：它是一個運行在你的主機系統上但是爲你的目標系統(和處理器)生成代碼的工具鏈。舉例來說，如果你的主機系統用的是x86處理器，你的目標系統用的是ARM處理器，你主機上的這個普通的編譯工具鏈運行在你的x86處理器上並且爲x86生成代碼，但是交叉編譯工具運行在你的x86處理器上但是爲ARM生成代碼
及時你的嵌入式系統用的是一個x86處理器，你也可能對Buildroot產生情趣，主要原因有以下兩點：
· 顯然，你的主機系統上的編譯工具集用的是GNU Libc，GNU Libc是一個完整的標準庫，但是它體積龐大。與你在你的目標系統上使用GNU Libc相比，你可以使用uClibc，uClibc是一個很微小的標準C庫。如果你想使用這個C庫，你需要一個編譯工具集來生成二進制工具去鏈接它。Buldroot能夠替你完成這些事。
· Buildroot 自動地使用工具如busybox來建立一個根文件系統。它比手工完成一個根文件系統的製作更簡單。
你可能很好奇了，爲什麼這樣一個工具在你手工編譯gcc、binutils、uClibc和其他所有的工具的時候是必須的。當然，手工完成它也是可能的。但是在處理所有的配置選項的時候，由於所有的問題如每一個gcc或者binutls版本都是耗費時間和令人厭倦的Buildroot通過使用Makefiles文件來自動操作這個過程，並且收集了每一個gcc和binutils版本的補丁，使他們能應用於更過的體系架構上面。
獲取 Buildroot
Buildroot通過每天的SVN鏡像文件或者直接使用SVN就可以得到。最新的鏡像文件一直都放置在 http://buildroot.uclibc.org/downloads/snapshots/buildroot-snapshot.tar.bz2，並且之前的鏡像也是放置在 http://buildroot.uclibc.org/downloads/snapshots/.
使用SVN來下載Buildroot，你可以簡單的使用uClibc buildroot 網站(http://buildroot.uclibc.org)下面的“Accessing SVN”頁面(http://buildroot.uclibc.org/subversion.html)裏描述的規則，並且下載SVN的各個模塊。爲了不讓你着急，下面是一個簡介的方法：
$ svn co svn://uclibc.org/trunk/buildroot
使用 Buildroot
Buildroot有一個較好的配置工具，就像你在Linux(http://www.kernel.org/)內核和Busybox(http://www.busybox.org/)裏面看到的類似。 注意的是你作爲一個普通用戶，你可以在裏面構造任何東西。這裏不需要你是一個超級用戶來配置和是用Buildroot。第一步是運行配置助手：
$ make menuconfig
對於配置的每個條目來說，你都可以找到相關聯的幫助，幫助信息描述了該條目的用途。
一個關鍵的配置項目是PROFECT，它決定了在構建這些包的位置，以及結果安裝的位置。
一旦所有的都配置完成了，配置工具將產生一個.config文件，裏面包含了了你的配置信息，它將會被Makefile使用，來決定需要哪些文件。
讓我們繼續：
$ make
這個命令將下載、配置並且編譯所有被選擇的工具，並且最後產生一個目標文件系統。這個目標文件系統被命名爲root_fs_ARCH.EXT,ARCH是你的處理器架構類型，EXT依賴於你在配置工具中選擇的目標文件系統。這個文件存放在“binaries/$(PROJECT)/”目錄裏面。
創建你自己的目標板支持
一旦一個包被打開了，就可以手動的升級配置文。Buildroot能自動的保存buildroot、linux、busybox、uclibc和u-boot的配置文件，存放在 “local/$(PROJECT) ”中，使用的命令如下：
$ make saveconfig
一旦一個buildroot的配置文件同過saveconfig被創建了，缺省的“$(TOPDIR)/.config” 文件就可以通過下面的方式被覆蓋了：
$ make BOARD=<project>
Buildroot以後會使用 “local/<project>/<project>.config”而不是“.config”。
如果你想修改你的目標板，你可以使用下面的命令來複制該工程的配置文件到“.config”:
$ make BOARD=<project> getconfig
你可以設置環境變量BUILDROOT_LOCAL使它指向這個目錄來在多個buildroot樹中共享你定製的目標板支持的文件夾。
離線構建
如果你想離線構建，並且僅僅是想下載之前在“make menuconfig”中選擇了的所有的源代碼，執行如下：
$ make source
你現在可以斷開連接，複製你的dl目錄中的內容到你的build-host。
環境變量
Buildroot可以選擇的遵循了部分已經通過的環境變量：
· HOSTCXX
· HOSTCC
· UCLIBC_CONFIG_FILE=<path/to/.config>
· BUSYBOX_CONFIG_FILE=<path/to/.config>
一個例子，使用config文件來定位頂級目錄文件夾和你的$HOME:
$ make UCLIBC_CONFIG_FILE=uClibc.config BUSYBOX_CONFIG_FILE=$HOME/bb.config
如果你想在你的主機上使用一個編譯器而不是缺省的gcc或者是g++來構建helper-binaries，執行如下：
$ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD
使用自動完成
如果你很懶散，你不想打字打出make menuconfigminglingh，你可以在你的shell中使用自動完成。這裏是怎麼樣你纔可以使用你的bash：
$ complete -W menuconfig make
然後只是打出一行開頭的字符，通過按TAB鍵來調用bash去完成它:
$ make me<TAB>
這樣bash就會爲你附加上nuconfig！
作爲選擇，有些發行版（其中Debian和Mandriva就是一個例子）可以更好的補充。根據你的發行版本，你可能必須安裝一些軟件包以便完成. 在Mandriva上，這個包爲bash-completion, 而Debian把它作爲了bash軟件包的一部分。
其他的shells，比如zsh, 也有完成這個任務的措施。具體的查看你的shell的文檔。
定製目標文件系統
這裏有一些定製最終目標文件系統的方法：
· 直接定製目標文件系統，並且重建映像文件。目標文件系統存放在project_build_ARCH/root/ 目錄下面，這裏的ARCH就是你選擇的目標架構。你可以很簡單的在這裏修改，並且重新編譯來重建目標文件系統。這個方法允許你在目標文件系統上進行任何的改變，但是如果你決定完全重新構建你的工具鏈和工具集，這些修改都會被被丟失。
· 定製目標文件系統框架，存放在target/generic/target_skeleton/目錄下面，你可以在這裏自定義配置文件或者其他東西。但是，完整的目錄層次還沒有實現，它是在編譯的過程中創建的。所以你不能在這個文件系統框架上做任何事情，即使你完全重建了交叉編譯工具鏈和工具集，但是這種改變依然被存在。
你也可以自定義target/generic/device_table.txt 文件，它是被工具集用來創建目標文件系統的權限設置和設備節點。target/generic/skel.tar.gz 文件包含了根文件系統的主要文件夾，而且我們沒有要去改變它。在這個壓縮包裏面的主要文件目錄都在框架裏面，因爲它包含了指向框架的符號鏈接，以防被損壞。
這些自定義配置在真正的映像產生之前將被展開到project_build_ARCH/root/ 目錄裏面。所以通過運行make來重建映像會把所有的修改都傳遞到映像裏面。
· 當使用make menuconfig來配置要建立的系統時，你可以指定在PROJECT 中的/etc/hostname和/etc/issue (歡迎條)的內容。
定製Busybox的配置
Busybox是完全可以配置的，而且你也想定製它。你可以遵循下面的簡單步驟來配置它，它不是最佳的方式，但是它最簡單額日期額可以正常工作。
1. 首先使用buildroot運行一次busybox，在這一次裏面不需要進行任何的配置。
2. 調用make busybox-menuconfig。這個配置工具使你可以電腦告知所有的東西。
3. 再一此運行編譯buildroot的編譯。
另外，如果你知道你想要的修改的選項而不需要配置工具的話，你也可以修改package/busybox/busybox-<version>.config 文件 。
如果你想使用busybox的已經存在的配置文件，請參照後面的環境變量。
定製uClibc的配置
就像BusyBox一樣，uClibc提供了許多配置選項。 他們允許你根據你不同的需求和侷限性選擇不同的功能。
最簡單的修改uClibc配置的步驟如下：
1. 首先不定製uClibc來編譯運行一次buildroot。
2. 調用make uclibc-menuconfig。這是一個很好的配置工具，它與曾在Linux內核和Buildroot裏面所使用的類似。然後進行你的正確配置。
3. 拷貝.config到toolchain/uClibc/uClibc.config或者是到 toolchain/uClibc/uClibc.config-locale。如果你沒有在Buildroot裏面選擇本地支持的話就使用前者，相反就用後者。
4. 再一此運行編譯buildroot的編譯。
另外，你也可以直接修改toolchain/uClibc/uClibc.config或者 toolchain/uClibc/uClibc.config-locale而不需要使用上面的配置工具。
如果你想使用一個已經存在uclibc配置文件，I請參照後面的環境變量。
Buildroot的運行方式
如上面所說的一樣， Buildroot是一個基本的並使用恰當的選項去下載、配置、編譯軟件的命令集。它還包括了一些軟件的補丁，主要的都是與交叉編譯工具鏈有關 (gcc，binutils 和uClibc)。
主要的是每一個軟件都有一個Makefile文件，他們都被命名爲以.mk爲擴展名。Makefiles主要分成以下四部分：
· 工程 (在 project/ 目錄) 包含了在這個相同buildroot目錄樹裏面涉及到構建根文件系統Makefiles和相關聯的文件。
· 工具鏈 (在toolchain/ 目錄) 包含了所有的設計到交叉工具鏈（binutils，ccache, gcc，gdb，kernel-headers and uClibc）的Makefiles和相關聯的文件。
· 包 (在package/ 目錄) 包含了Buildroot編譯並要加載到目標系統上的用戶空間的工具的Makefiles和相關聯的文件。對於每一個工具都有想對應的子目錄。.
· 目標 (在target/目錄) 包含了用於生成一目標文件系統映像的軟的Makefiles和相關文件。有四種類型的文件系統被支持：ext2，jffs2，cramfs和squashfs。他們中的每一個，都有一個子目錄來存放需要的文件。這裏也有一個缺省的default/ 目錄，裏面包含了目標文件系統的框架。
每個文件夾至少包含兩個文件：
· something.mk 是一個用於下載、配置、編譯和安裝的Makefile。
· Config.in是配置工具描述文件的一部分，它描述了當前軟件的相關選項。
核心的Makefile文件通過下面的步驟來完成任務（在配置完成以後）：
1. 創建下載目錄(缺省的爲dl/)。該目錄就是被下載的壓縮包存放的地方。非常有必要去了解該目錄下的壓縮包，我們可以將它保存到其他地方以免將來使用的時候再去下載。
2. 創建共享的構建目錄(缺省的爲build_ARCH/ ，ARCH是目標系統的體系架構)。在這個目錄裏面存放的是已經被編譯了的不需要配置的用戶空間的工具。當使用同一架構構建多個目標系統的時候，首先構建的會完全的通過下載、配置、編譯等步驟，但是第二個或者以後的就只需要拷貝第一次的結果，主要可以加速構建的進度。
3. 創建工程的詳細目錄 (缺省的爲project_build_ARCH/$(PROJECT), ARCH是目標系統的體系架構)。這裏是所有的可配置的用戶空間工具的被編譯的目錄。這個特殊的構建目錄是必須的, 如果兩個不用的目標體系架構都需要使用一個特殊的軟件包，這樣這個軟件包就根據目標體系架構有不同的配置，busybox和linux就是其中的例子。
4. 創建工程的結果目錄(缺省的爲binaries/$(PROJECT)，ARCH是目標系統的體系架構)。這個目錄是根文件系統映像存放的地方，也是存放目標系統的Linux內核映像和其他工具集、boot-loaders 等的地方。
5. 創建工具鏈目錄(缺省的爲toolchain_build_ARCH/，ARCH是目標系統的體系架構)。在這裏交叉工具鏈被編譯。
6. 設置平臺目錄(缺省的爲build_ARCH/staging_dir/)。這裏是交叉編譯工具鏈安裝的地方。如果你想使用相同的交叉編譯工具鏈來作爲其他的用途，比如說編譯第三方的應用軟件，你可以添加build_ARCH/staging_dir/usr/b路徑到PATH中，只有你就可以使用arch-linux-gcc來編譯你的程序了。爲了設置這個目錄，首先應該移除這個它，然後它在該目錄裏面創建子目錄和符號連接。
7. 創建目標文件系統 (缺省的爲project_build_ARCH/root/) 和目標文件系統框架。這個目錄將包含最終的根文件系統。要使它更新，首先應該刪除它，然後解壓 target/generic/skel.tar.gz 文件來創建主要的子目錄文件夾和符號鏈接，並拷貝在target/generic/target_skeleton中可用的框架，然後刪除沒有用的.svn/目錄。
8. 添加TARGETS的依賴關係。一般將會檢查這些包的配置選項是否可用，然後通過把它添加到TARGETS全局變量中來定製要被編譯的軟件包。
在相同的buildroot源代碼目錄樹構建幾個不同的工程
背景知識
如果每個工程都是爲不同的體系架構構建的話，buildroot支持在同一個源代碼目錄樹中構建若干不同的工程。
根文件系統被創建在“build_<ARCH>/root”文件夾中，對於每一個體系架構來說，它都是唯一的。交叉工具鏈被建立在“toolchain_build_<ARCH>”目錄。
如果用戶希望爲相同的體系架構構建若干個根文件系統，就應該在配置中加上前綴或者後綴，這樣的話，建立的根文件系統就被放置在“<PREFIX>_build_<ARCH>_<SUFFIX>/root”。通過設置唯一的前綴和後綴，使每一個工程都有一個唯一的根文件系統樹。
這個方法的缺點就是爲同一個芯片建立兩個工程，每一個工程都要建立一個新的工具鏈，這個構建過程將耗費更多的時間。
如果使用的是gcc-4.x.y 的話，這個缺點就不是那麼的明顯了，因爲gcc-4.x.y 允許使用外部工具鏈。由於某些軟件包需要一些特殊功能，如果使用的一個外部的工具鏈，這可能就缺少一些必要的功能，來構建一個根文件系統。
一個更大的問題是build_<ARCH>目錄樹也是拷貝的，這樣的話，每個軟件包也都爲每一個工程重建一次，導致花費更長的時間。
共享工程的工具鏈和構建的軟件包
當工作在一個工程的時候，允許用戶在同一個目錄樹爲同一個體系架構構建多個根目錄樹。工具鏈個軟件包的構建目錄將會被共享，但是每一個具體的工程都有一個專門的目錄。
在使用的這個方法的時候，更多的是，如果在第一個工程建立時，所有的軟件包都沒有被編譯。這個過程就幾乎同原來的過程一樣了，所有下載的軟件包被下載然後提取到共享目錄“build_<ARCH>/<package>”中，然後配置、編譯。
二進制軟件包和頭文件被安裝到共享目錄$(STAGING_DIR)中，然後這個工程專門的根文件系統被設置到“$(TARGET_DIR)”。
在構建結束的時候，還要通過這個根文件系統來生成一個最後的二進制根文件系統。
一旦第一個工程構建結束，在構建其他工程的時候就只是調用已經共享在“build_<ARCH>/<>”目錄下的內容來生成新的文件系統。
如果一些軟件包沒有用於第一個工程，就只能通過提取-配置-編譯的步驟了。
執行
核心是要建立兩個新的目錄：
· project_build_<ARCH>
· binaries；
每個目錄裏面都包含了每個工程的子目錄。子目錄的名字是用戶在配置buildroot的時候配置的，它由下面的內容組成：
Project Options ---> Project name
這裏定義$(PROJECT)變量。
缺省的名字（project name）爲“uclibc”。
"package/Makefile.in"定義爲：
PROJECT_BUILD_DIR:=project_build_$(ARCH)/$(PROJECT)
BINARIES_DIR:=binaries/$(PROJECT)
它也定義了目標根文件系統的本地路徑：
TARGET_DIR:=$(PROJECT_BUILD_DIR)/$(PROJECT)/root
也就是說：如果用戶使用“myproject”作爲$(PROJECT) 名稱：
· "project_build_<ARCH>/myproject"
· "binaries/myproject"
就會被創建。
現在，根文件系統，busybox和AtmelU-Boot版本，還有Atmel專門的一些bootloader像阿通1-bootstrap和dataflashboot.bin都被構建在“$(PROJECT_BUILD_DIR)”中。
所有體系架構最後的二進制文件都存放在“$(BINARIES_DIR)”目錄中。
總結
工程將會共享不會引起衝突的文件夾，但是使用唯一的構建目錄，在該目錄中，用戶可以配置自己的配置。
該做的事情
1. Linux
當前的Linux版本總是有缺陷的， 它僅僅工作在用戶選擇使用較少額選項作爲內核基本的頭文件。它僅服務於用戶選擇的少量的內核作爲主要內核的基礎。雖然Makefle有一些關聯，允許開發者在target/device/*/* Makefiles中指定內核的版本，但是如果選擇了其他的版本，構建將會失敗的。
原因是內核的補丁沒有被"target/linux/linux.mk"用來編譯腳本片段。他們僅用於"toolchain/kernel-headers/*.makefile"去編譯腳本片段。
如果內核頭文件和Linux版本不一樣的話，在“build_<ARCH>/<>”將會有兩個“linux-2.6.X.Y”文件夾，每一個都自己的補丁命令。
在這個方案中的解決辦法是，將Linux的構建目錄移動到“project_build_<ARCH>/<project name>/linux-2.6.X.Y”，結合這個方法把可以應用的補丁進行配置。用於產生頭文件的Linux的源代碼目錄樹很可能會被移動到“toolchain_build_<ARCH>”目錄中去。
用戶可以選擇下面三種不同的策略：
o 保守策略: 僅僅使用內核頭文件支持的版本
o 穩定Linux的策略: 允許任何的2.6.X.Y 的組合體（最小爲2.6.19）
o 激進用戶策略: 允許“-git”或者是“-mm”，或者是用戶下載內核
The current kernel patches can be configured to be applied to the linux source tree even if the version differs from the kernel header version.
Since the user can select any kernel-patch he/she will be able to select a non-working combination. If the patch fails, the user will have to generate a new proprietary kernel-patch or decide to not apply the kernel patches
Other optional patches will be board specific or architecture specific patches.
There will also be a way for the user to supply absolute or relative paths to patches, possibly outside the main tree. This can be used to apply custom kernel-header-patches, if the versions available in buildroot cannot be applied to the specific linux version used
Maybe, there will also be a possibility to supply an "URL" to a patch available on Internet.
2. Configurable packages
Many packages can, on top of the simple "enable/disable build", be further configured using Kconfig. Currently these packages will be compiled using the configuration specified in the ".config" file of the first project demanding the build of the package.
If another project uses the same packages, but with a different configuration,these packages will not be rebuilt, and the root file system for the new project will be populated with files from the build of the first project
If multiple project are built, and a specific package needs two different configuration, then the user must delete the package from the "build_<ARCH>" directory before rebuilding the new project.
A long term solution is to edit the package makefile and move the build of the configurable packages from "build_<ARCH>" to "project_build_<ARCH>/<project name>" and send a patch to the buildroot mailing list.
3. Naming conventions
Names of resulting binaries should reflect the "project name"
4. Generating File System binaries
Packages which needs to be installed with the "root" as owner, will generate a ".fakeroot.<package>" file which will be used for the final build of the root file system binary.
This was previously located in the "$(STAGING_DIR)" directory, but was recently moved to the "$(PROJECT_BUILD_DIR)" directory.
Currently only three packages: "at", "ltp-testsuite" and "nfs-utils" requests fakeroot.
The makefile fragments for each file system type like "ext2", "jffs2" or "squashfs" will, when the file system binary is generated, collect all present ".fakeroot.<package>" files to a single "_fakeroot.<file system>" file and call fakeroot.
".fakeroot.<package>" files are deleted as the last action of the Buildroot Makefile.
It needs to be evaluated if any further action for the file system binary build is needed.
Using the uClibc toolchain
You may want to compile your own programs or other software that are not packaged in Buildroot. In order to do this, you can use the toolchain that was generated by Buildroot.
The toolchain generated by Buildroot by default is located in build_ARCH/staging_dir/. The simplest way to use it is to add build_ARCH/staging_dir/usr/bin/ to your PATH environnement variable, and then to use arch-linux-gcc, arch-linux-objdump, arch-linux-ld, etc.
For example, you may add the following to your .bashrc (considering you're building for the MIPS architecture and that Buildroot is located in ~/buildroot/) :
export PATH="$PATH:~/buildroot/build_mips/staging_dir/usr/bin/"
Then you can simply do :
mips-linux-gcc -o foo foo.c
Important : do not try to move a gcc-3.x toolchain to an other directory, it won't work. There are some hardcoded paths in the gcc configuration. If the default toolchain directory doesn't suit your needs, please refer to the Using the uClibc toolchain outside of buildroot section.
If you are using a current gcc-4.x, then use --sysroot and -isysroot since these toolchains have fully functional sysroot support. No hardcoded paths do exist in these configurations.
Using the uClibc toolchain outside of buildroot
By default, the cross-compilation toolchain is generated inside build_ARCH/staging_dir/. But sometimes, it may be useful to install it somewhere else, so that it can be used to compile other programs or by other users. Moving the build_ARCH/staging_dir/ directory elsewhere is not possible if using gcc-3.x, because there are some hardcoded paths in the toolchain configuration. This works, thanks to sysroot support, with current, stable gcc-4.x toolchains, of course.
If you want to use the generated gcc-3.x toolchain for other purposes, you can configure Buildroot to generate it elsewhere using the option of the configuration tool : Build options -> Toolchain and header file location, which defaults to $(BUILD_DIR)/staging_dir/.
Location of downloaded packages
It might be useful to know that the various tarballs that are downloaded by the Makefiles are all stored in the DL_DIR which by default is the dl directory. It's useful for example if you want to keep a complete version of Buildroot which is know to be working with the associated tarballs. This will allow you to regenerate the toolchain and the target filesystem with exactly the same versions.
If you maintain several buildroot trees, it might be better to have a shared download location. This can be accessed by creating a symbolic link from the dl directory to the shared download location.
I.E:
ln -s <shared download location> dl
Another way of accessing a shared download location is to create the BUILDROOT_DL_DIR environment variable. If this is set, then the value of DL_DIR in the project is overridden. The following line should be added to "~/.bashrc".
export BUILDROOT_DL_DIR <shared download location>
Extending Buildroot with more software
This section will only consider the case in which you want to add user-space software.
Package directory
First of all, create a directory under the package directory for your software, for example foo.
Config.in file
Then, create a file named Config.in. This file will contain the portion of options description related to our foo software that will be used and displayed in the configuration tool. It should basically contain :
config BR2_PACKAGE_FOO
bool "foo"
default n
help
This is a comment that explains what foo is.
Of course, you can add other options to configure particular things in your software.
The real Makefile
Finally, here's the hardest part. Create a file named foo.mk. It will contain the Makefile rules that are in charge of downloading, configuring, compiling and installing the software. Below is an example that we will comment afterwards.
1 #############################################################
2 #
3 # foo
4 #
5 #############################################################
6 FOO_VERSION:=1.0
7 FOO_SOURCE:=foo-$(FOO_VERSION).tar.gz
8 FOO_SITE:=http://www.foosoftware.org/downloads
9 FOO_DIR:=$(BUILD_DIR)/foo-$(FOO_VERSION)
10 FOO_BINARY:=foo
11 FOO_TARGET_BINARY:=usr/bin/foo
12
13 $(DL_DIR)/$(FOO_SOURCE):
14 $(WGET) -P $(DL_DIR) $(FOO_SITE)/$(FOO_SOURCE)
15
16 $(FOO_DIR)/.source: $(DL_DIR)/$(FOO_SOURCE)
17 $(ZCAT) $(DL_DIR)/$(FOO_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) -
18 touch $@
19
20 $(FOO_DIR)/.configured: $(FOO_DIR)/.source
21 (cd $(FOO_DIR); rm -rf config.cache; /
22 $(TARGET_CONFIGURE_OPTS) /
23 $(TARGET_CONFIGURE_ARGS) /
24 ./configure /
25 --target=$(GNU_TARGET_NAME) /
26 --host=$(GNU_TARGET_NAME) /
27 --build=$(GNU_HOST_NAME) /
28 --prefix=/usr /
29 --sysconfdir=/etc /
30 )
31 touch $@
32
33 $(FOO_DIR)/$(FOO_BINARY): $(FOO_DIR)/.configured
34 $(MAKE) CC=$(TARGET_CC) -C $(FOO_DIR)
35
36 $(TARGET_DIR)/$(FOO_TARGET_BINARY): $(FOO_DIR)/$(FOO_BINARY)
37 $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) install
38 rm -Rf $(TARGET_DIR)/usr/man
39
40 foo: uclibc ncurses $(TARGET_DIR)/$(FOO_TARGET_BINARY)
41
42 foo-source: $(DL_DIR)/$(FOO_SOURCE)
43
44 foo-clean:
45 $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) uninstall
46 -$(MAKE) -C $(FOO_DIR) clean
47
48 foo-dirclean:
49 rm -rf $(FOO_DIR)
50
51 #############################################################
52 #
53 # Toplevel Makefile options
54 #
55 #############################################################
56 ifeq ($(strip $(BR2_PACKAGE_FOO)),y)
57 TARGETS+=foo
58 endif
First of all, this Makefile example works for a single binary software. For other software such as libraries or more complex stuff with multiple binaries, it should be adapted. Look at the other *.mk files in the package directory.
At lines 6-11, a couple of useful variables are defined :
· FOO_VERSION : The version of foo that should be downloaded.
· FOO_SOURCE : The name of the tarball of foo on the download website of FTP site. As you can see FOO_VERSION is used.
· FOO_SITE : The HTTP or FTP site from which foo archive is downloaded. It must include the complete path to the directory where FOO_SOURCE can be found.
· FOO_DIR : The directory into which the software will be configured and compiled. Basically, it's a subdirectory of BUILD_DIR which is created upon decompression of the tarball.
· FOO_BINARY : Software binary name. As said previously, this is an example for a single binary software.
· FOO_TARGET_BINARY : The full path of the binary inside the target filesystem.
Lines 13-14 defines a target that downloads the tarball from the remote site to the download directory (DL_DIR).
Lines 16-18 defines a target and associated rules that uncompress the downloaded tarball. As you can see, this target depends on the tarball file, so that the previous target (line 13-14) is called before executing the rules of the current target. Uncompressing is followed by touching a hidden file to mark the software has having been uncompressed. This trick is used everywhere in Buildroot Makefile to split steps (download, uncompress, configure, compile, install) while still having correct dependencies.
Lines 20-31 defines a target and associated rules that configures the software. It depends on the previous target (the hidden .source file) so that we are sure the software has been uncompressed. In order to configure it, it basically runs the well-known ./configure script. As we may be doing cross-compilation, target, host and build arguments are given. The prefix is also set to /usr, not because the software will be installed in /usr on your host system, but in the target filesystem. Finally it creates a .configured file to mark the software as configured.
Lines 33-34 defines a target and a rule that compiles the software. This target will create the binary file in the compilation directory, and depends on the software being already configured (hence the reference to the .configured file). It basically runs make inside the source directory.
Lines 36-38 defines a target and associated rules that install the software inside the target filesystem. It depends on the binary file in the source directory, to make sure the software has been compiled. It uses the install target of the software Makefile by passing a prefix argument, so that the Makefile doesn't try to install the software inside host /usr but inside target /usr. After the installation, the /usr/man directory inside the target filesystem is removed to save space.
Line 40 defines the main target of the software, the one that will be eventually be used by the top level Makefile to download, compile, and then install this package. This target should first of all depends on all needed dependecies of the software (in our example, uclibc and ncurses), and also depend on the final binary. This last dependency will call all previous dependencies in the correct order.
Line 42 defines a simple target that only downloads the code source. This is not used during normal operation of Buildroot, but is needed if you intend to download all required sources at once for later offline build. Note that if you add a new package providing a foo-source target is mandatory to support users that wish to do offline-builds. Furthermore it eases checking if all package-sources are downloadable.
Lines 44-46 define a simple target to clean the software build by calling the Makefiles with the appropriate option. The -clean target should run make clean on $(BUILD_DIR)/package-version and MUST uninstall all files of the package from $(STAGING_DIR) and from $(TARGET_DIR).
Lines 48-49 define a simple target to completely remove the directory in which the software was uncompressed, configured and compiled. The -dirclean target MUST completely rm $(BUILD_DIR)/ package-version.
Lines 51-58 adds the target foo to the list of targets to be compiled by Buildroot by first checking if the configuration option for this package has been enabled using the configuration tool, and if so then "subscribes" this package to be compiled by adding it to the TARGETS global variable. The name added to the TARGETS global variable is the name of this package's target, as defined on line 40, which is used by Buildroot to download, compile, and then install this package.
Conclusion
As you can see, adding a software to buildroot is simply a matter of writing a Makefile using an already existing example and to modify it according to the compilation process of the software.
If you package software that might be useful for other persons, don't forget to send a patch to Buildroot developers !
Resources
To learn more about Buildroot you can visit these websites:
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/songguozhi/archive/2008/10/16/3085718.aspx