buildroot-documentation.html 26 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607
  1. <?xml version="1.0" encoding="iso-8859-1"?>
  2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  3. "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
  4. <html xmlns="http://www.w3.org/1999/xhtml">
  5. <head>
  6. <title>Buildroot - Usage and documentation</title>
  7. <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
  8. <link rel="stylesheet" type="text/css" href="stylesheet.css" />
  9. </head>
  10. <body>
  11. <div class="main">
  12. <div class="titre">
  13. <h1>Buildroot</h1>
  14. </div>
  15. <p>Usage and documentation by Thomas Petazzoni. Contributions from
  16. Karsten Kruse, Ned Ludd, Martin Herren.</p>
  17. <p><small>Last modification : $Date: 2004/12/27 19:01:52 $</small></p>
  18. <ul>
  19. <li><a href="#about">About Buildroot</a></li>
  20. <li><a href="#download">Obtaining Buildroot</a></li>
  21. <li><a href="#using">Using Buildroot</a></li>
  22. <li><a href="#custom_targetfs">Customizing the target filesystem</a></li>
  23. <li><a href="#custom_busybox">Customizing the Busybox
  24. configuration</a></li>
  25. <li><a href="#custom_uclibc">Customizing the uClibc
  26. configuration</a></li>
  27. <li><a href="#buildroot_innards">How Buildroot works</a></li>
  28. <li><a href="#toolchain_standalone">Using the uClibc toolchain without
  29. Buildroot</a></li>
  30. <li><a href="#downloaded_packages">Location of downloaded packages</a></li>
  31. <li><a href="#add_software">Extending Buildroot with more
  32. Software</a></li>
  33. <li><a href="#links">Ressources</a></li>
  34. </ul>
  35. <h2><a name="about" id="about"></a>About Buildroot</h2>
  36. <p>Buildroot is a set of Makefiles and patches that allows to easily
  37. generate both a cross-compilation toolchain and a root filesystem for your
  38. target. The cross-compilation toolchain uses uClibc (<a href=
  39. "http://www.uclibc.org/">http://www.uclibc.org/</a>), a tiny C standard
  40. library.</p>
  41. <p>Buildroot is useful mainly for people working with embedded systems.
  42. Embedded systems often use processors that are not the regular x86
  43. processors everyone is used to have on his PC. It can be PowerPC
  44. processors, MIPS processors, ARM processors, etc.</p>
  45. <p>A compilation toolchain is the set of tools that allows to
  46. compile code for your system. It consists of a compiler (in our
  47. case, <code>gcc</code>), binary utils like assembler and linker
  48. (in our case, <code>binutils</code>) and a C standard library (for
  49. example <a href="http://www.gnu.org/software/libc/libc.html">GNU
  50. Libc</a>, <a href="http://www.uclibc.org">uClibc</a> or <a
  51. href="http://www.fefe.de/dietlibc/">dietlibc</a>). The system
  52. installed on your development station certainly already has a
  53. compilation toolchain that you can use to compile application that
  54. runs on your system. If you're using a PC, your compilation
  55. toolchain runs on an x86 processor and generates code for a x86
  56. processor. Under most Linux systems, the compilation toolchain
  57. uses the GNU libc as C standard library. This compilation
  58. toolchain is called the "host compilation toolchain", and more
  59. generally, the machine on which it is running, and on which you're
  60. working is called the "host system". The compilation toolchain is
  61. provided by your distribution, and Buildroot has nothing to do
  62. with it.</p>
  63. <p>As said above, the compilation toolchain that comes with your system
  64. runs and generates code for the processor of your host system. As your
  65. embedded system has a different processor, you need a cross-compilation
  66. toolchain: it's a compilation toolchain that runs on your host system but
  67. that generates code for your target system (and target processor). For
  68. example, if your host system uses x86 and your target system uses ARM, the
  69. regular compilation toolchain of your host runs on x86 and generates code
  70. for x86, while the cross-compilation toolchain runs on x86 and generates
  71. code for ARM.</p>
  72. <p>Even if your embedded system uses a x86 processor, you might interested
  73. in Buildroot, for two reasons:</p>
  74. <ul>
  75. <li>The compilation toolchain of your host certainly uses the GNU Libc
  76. which is a complete but huge C standard library. Instead of using GNU
  77. Libc on your target system, you can use uClibc which is a tiny C standard
  78. library. If you want to use this C library, then you need a compilation
  79. toolchain to generate binaries linked with it. Buildroot can do it for
  80. you.</li>
  81. <li>Buildroot automates the building of a root filesystem with all needed
  82. tools like busybox. It makes it much easier than doing it by hand.</li>
  83. </ul>
  84. <p>You might wonder why such a tool is needed when you can compile
  85. <code>gcc</code>, <code>binutils</code>, uClibc and all the tools by hand.
  86. Of course, doing so is possible. But dealing with all configure options,
  87. with all problems of every <code>gcc</code> or <code>binutils</code>
  88. version it very time-consuming and uninteresting. Buildroot automates this
  89. process through the use of Makefiles, and has a collection of patches for
  90. each <code>gcc</code> and <code>binutils</code> version to make them work
  91. on most architectures.</p>
  92. <h2><a name="download" id="download"></a>Obtaining Buildroot</h2>
  93. <p>Buildroot is available as daily CVS snapshots or directly using
  94. CVS.</p>
  95. <p>The latest snapshot is always available at <a
  96. href="http://uclibc.org/downloads/snapshots/buildroot-snapshot.tar.bz2">http://uclibc.org/downloads/snapshots/buildroot-snapshot.tar.bz2</a>,
  97. and previous snapshots are also available at <a
  98. href="http://uclibc.org/downloads/snapshots/">http://uclibc.org/downloads/snapshots/</a>.</p>
  99. <p>To download Buildroot using CVS, you can simply follow
  100. the rules described on the "Accessing CVS"-page (<a href=
  101. "http://www.uclibc.org/cvs_anon.html">http://www.uclibc.org/cvs_anon.html</a>)
  102. of the uClibc website (<a href=
  103. "http://www.uclibc.org">http://www.uclibc.org</a>), and download the
  104. <code>buildroot</code> CVS module. For the impatient, here's a quick
  105. recipe:</p>
  106. <pre>
  107. $ cvs -d:pserver:anonymous@uclibc.org:/var/cvs login
  108. $ cvs -z3 -d:pserver:anonymous@uclibc.org:/var/cvs co buildroot
  109. </pre>
  110. <h2><a name="using" id="using"></a>Using Buildroot</h2>
  111. <p>Buildroot has a nice configuration tool similar to the one you can find
  112. in the Linux Kernel (<a href=
  113. "http://www.kernel.org/">http://www.kernel.org/</a>) or in Busybox
  114. (<a href="http://www.busybox.org/">http://www.busybox.org/</a>). Note that
  115. you can run everything as a normal user. There is no need to be root to
  116. configure and use Buildroot. The first step is to run the configuration
  117. assistant:</p>
  118. <pre>
  119. $ make menuconfig
  120. </pre>
  121. <p>For each entry of the configuration tool, you can find associated help
  122. that describes the purpose of the entry.</p>
  123. <p>Once everything is configured, the configuration tool has generated a
  124. <code>.config</code> file that contains the description of your
  125. configuration. It will be used by the Makefiles to do what's needed.</p>
  126. <p>Let's go:</p>
  127. <pre>
  128. $ make
  129. </pre>
  130. <p>This command will download, configure and compile all the selected
  131. tools, and finally generate a target filesystem. The target filesystem will
  132. be named <code>root_fs_ARCH.EXT</code> where <code>ARCH</code> is your
  133. architecture and <code>EXT</code> depends on the type of target filesystem
  134. selected in the <code>Target options</code> section of the configuration
  135. tool.</p>
  136. <h2><a name="custom_targetfs" id="custom_targetfs"></a>Customizing the
  137. target filesystem</h2>
  138. <p>There are two ways to customize the resulting target filesystem:</p>
  139. <ul>
  140. <li>Customize the target filesystem directly, and rebuild the image. The
  141. target filesystem is available under <code>build_ARCH/root/</code> where
  142. <code>ARCH</code> is the chosen target architecture. You can simply make
  143. your changes here, and run make afterwards, which will rebuild the target
  144. filesystem image. This method allows to do everything on the target
  145. filesystem, but if you decide to completely rebuild your toolchain and
  146. tools, these changes will be lost.</li>
  147. <li>Customize the target filesystem skeleton, available under
  148. <code>target/default/target_skeleton/</code>. You can customize
  149. configuration files or other stuff here. However, the full file hierarchy
  150. is not yet present, because it's created during the compilation process.
  151. So you can't do everything on this target filesystem skeleton, but
  152. changes to it remains even you completely rebuild the cross-compilation
  153. toolchain and the tools.<br />
  154. You can also customize the <code>target/default/device_table.txt</code>
  155. file which is used by the tools that generate the target filesystem image
  156. to properly set permissions and create device nodes. The
  157. <code>target/default/skel.tar.gz</code> file contains the main
  158. directories of a root filesystem and there is no obvious reason for which
  159. it should be changed. These main directories are in an tarball inside of
  160. inside the skeleton because it contains symlinks that would be broken
  161. otherwise.</li>
  162. </ul>
  163. <h2><a name="custom_busybox" id="custom_busybox"></a>Customizing the
  164. Busybox configuration</h2>
  165. <p>Busybox is very configurable, and you may want to customize it. You can
  166. follow these simple steps to do it. It's not an optimal way, but it's
  167. simple and it works.</p>
  168. <ol>
  169. <li>Make a first compilation of buildroot with busybox without trying to
  170. customize it.</li>
  171. <li>Go into <code>build_ARCH/busybox/</code> and run <code>make
  172. menuconfig</code>. The nice configuration tool appears and you can
  173. customize everything.</li>
  174. <li>Copy the <code>.config</code> file to
  175. <code>package/busybox/busybox.config</code> so that your customized
  176. configuration will remains even if you remove the cross-compilation
  177. toolchain.</li>
  178. <li>Run the compilation of buildroot again.</li>
  179. </ol>
  180. <p>Otherwise, you can simply change the
  181. <code>package/busybox/busybox.config</code> file if you know the options
  182. you want to change without using the configuration tool.</p>
  183. <h2><a name="custom_uclibc" id="custom_uclibc"></a>Customizing the uClibc
  184. configuration</h2>
  185. <p>Just like <a href="#custom_busybox">BusyBox</a>, <a
  186. href="http://www.uclibc.org">uClibc</a> offers a lot of
  187. configuration options. They allow to select various
  188. functionalities, depending on your needs and limitations.</p>
  189. <p>The easiest way to modify the configuration of uClibc is to
  190. follow these steps :</p>
  191. <ol>
  192. <li>Make a first compilation of buildroot without trying to
  193. customize uClibc.</li>
  194. <li>Go into the directory
  195. <code>toolchain_build_ARCH/uClibc/</code> and run <code>make
  196. menuconfig</code>. The nice configuration assistant, similar to
  197. the one used in the Linux Kernel or in Buildroot appears. Make
  198. your configuration as appropriate.</li>
  199. <li>Copy the <code>.config</code> file to
  200. <code>toolchain/uClibc/uClibc.config</code> or
  201. <code>toolchain/uClibc/uClibc.config-locale</code>. The former
  202. is used if you haven't selected locale support in Buildroot
  203. configuration, and the latter is used if you have selected
  204. locale support.
  205. <li>Run the compilation of Buildroot again</li>
  206. </ol>
  207. <p>Otherwise, you can simply change
  208. <code>toolchain/uClibc/uClibc.config</code> or
  209. <code>toolchain/uClibc/uClibc.config-locale</code> without running
  210. the configuration assistant.</p>
  211. <h2><a name="buildroot_innards" id="buildroot_innards"></a>How Buildroot
  212. works</h2>
  213. <p>As said above, Buildroot is basically a set of Makefiles that download,
  214. configure and compiles software with the correct options. It also includes
  215. some patches for various softwares, mainly the ones involved in the
  216. cross-compilation tool chain (<code>gcc</code>, <code>binutils</code> and
  217. uClibc).</p>
  218. <p>There is basically one Makefile per software, and they are named with
  219. the <code>.mk</code> extension. Makefiles are split into three
  220. sections:</p>
  221. <ul>
  222. <li><b>package</b> (in the <code>package/</code> directory) contains the
  223. Makefiles and associated files for all user-space tools that Buildroot
  224. can compile and add to the target root filesystem. There is one
  225. sub-directory per tool.</li>
  226. <li><b>toolchain</b> (in the <code>toolchain/</code> directory) contains
  227. the Makefiles and associated files for all softwares related to the
  228. cross-compilation toolchain : <code>binutils</code>, <code>ccache</code>,
  229. <code>gcc</code>, <code>gdb</code>, <code>kernel-headers</code> and
  230. <code>uClibc</code>.</li>
  231. <li><b>target</b> (in the <code>target</code> directory) contains the
  232. Makefiles and associated files for softwares related to the generation of
  233. the target root filesystem image. Four types of filesystems are supported
  234. : ext2, jffs2, cramfs and squashfs. For each of them, there's a
  235. sub-directory with the required files. There is also a
  236. <code>default/</code> directory that contains the target filesystem
  237. skeleton.</li>
  238. </ul>
  239. <p>Each directory contains at least 3 files :</p>
  240. <ul>
  241. <li><code>something.mk</code> is the Makefile that downloads, configures,
  242. compiles and installs the software <code>something</code>.</li>
  243. <li><code>Config.in</code> is a part of the configuration tool
  244. description file. It describes the option related to the current
  245. software.</li>
  246. <li><code>Makefile.in</code> is a part of Makefile that sets various
  247. variables according to the configuration given through the configuration
  248. tool. For most tools it simply involves adding the name of the tool to
  249. the <code>TARGETS</code> variable.</li>
  250. </ul>
  251. <p>The main Makefile do the job through the following steps (once the
  252. configuration is done):</p>
  253. <ol>
  254. <li>Create the download directory (<code>dl/</code> by default). This is
  255. where the tarballs will be downloaded. It is interesting to know that the
  256. tarballs are in this directory because it may be useful to save them
  257. somewhere to avoid further downloads.</li>
  258. <li>Create the build directory (<code>build_ARCH/</code> by default,
  259. where <code>ARCH</code> is your architecture). This is where all
  260. user-space tools while be compiled.</li>
  261. <li>Create the toolchain build directory
  262. (<code>toolchain_build_ARCH/</code> by default, where <code>ARCH</code>
  263. is your architecture). This is where the cross compilation toolchain will
  264. be compiled.</li>
  265. <li>Setup the staging directory (<code>build_ARCH/staging_dir/</code> by
  266. default). This is where the cross-compilation toolchain will be
  267. installed. If you want to use the same cross-compilation toolchain for
  268. other purposes, such as compiling third-party applications, you can add
  269. <code>build_ARCH/staging_dir/bin</code> to your PATH, and then use
  270. <code>arch-linux-gcc</code> to compile your application. In order to
  271. setup this staging directory, it first removes it, and then it creates
  272. various subdirectories and symlinks inside it.</li>
  273. <li>Create the target directory (<code>build_ARCH/root/</code> by
  274. default) and the target filesystem skeleton. This directory will contain
  275. the final root filesystem. To setup it up, it first deletes it, then it
  276. uncompress the <code>target/default/skel.tar.gz</code> file to create the
  277. main subdirectories and symlinks, copies the skeleton available in
  278. <code>target/default/target_skeleton</code> and then removes useless
  279. <code>CVS/</code> directories.</li>
  280. <li>Make the <code>TARGETS</code> dependency. This is where all the job
  281. is done : all <code>Makefile.in</code> files "subscribe" targets into
  282. this global variable, so that the needed tools gets compiled.</li>
  283. </ol>
  284. <h2><a name="toolchain_standalone" id="toolchain_standalone"></a>Using the
  285. uClibc toolchain without buildroot</h2>
  286. <p>By default, the cross-compilation toolchain is generated inside
  287. <code>build_ARCH/staging_dir/</code>. But sometimes, it may be useful to
  288. install it somewhere else, so that it can be used to compile other programs
  289. or by other users. Moving the <code>build_ARCH/staging_dir/</code>
  290. directory elsewhere is <b>not possible</b>, because they are some hardcoded
  291. paths in the toolchain configuration.</p>
  292. <p>If you want to use the generated toolchain for other purposes,
  293. you can configure Buildroot to generate it elsewhere using the
  294. option of the configuration tool : <code>Build options ->
  295. Toolchain and header file location</code>, which defaults to
  296. <code>$(BUILD_DIR)/staging_dir/</code>.</p>
  297. <h2><a name="downloaded_packages"
  298. id="downloaded_packages"></a>Location of downloaded packages</h2>
  299. <p>It might be useful to know that the various tarballs that are
  300. downloaded by the <i>Makefiles</i> are all stored in the
  301. <code>DL_DIR</code> which by default is the <code>dl</code>
  302. directory. It's useful for example if you want to keep a complete
  303. version of Buildroot which is know to be working with the
  304. associated tarballs. This will allow you to regenerate the
  305. toolchain and the target filesystem with exactly the same
  306. versions.</p>
  307. <h2><a name="add_software" id="add_software"></a>Extending Buildroot with
  308. more software</h2>
  309. <p>This section will only consider the case in which you want to
  310. add user-space software.</p>
  311. <h3>Package directory</h3>
  312. <p>First of all, create a directory under the <code>package</code>
  313. directory for your software, for example <code>foo</code>.</p>
  314. <h3><code>Config.in</code> file</h3>
  315. <p>Then, create a file named <code>Config.in</code>. This file
  316. will contain the portion of options description related to our
  317. <code>foo</code> software that will be used and displayed in the
  318. configuration tool. It should basically contain :</p>
  319. <pre>
  320. config BR2_PACKAGE_FOO
  321. bool "foo"
  322. default n
  323. help
  324. This is a comment that explains what foo is.
  325. </pre>
  326. <p>Of course, you can add other options to configure particular
  327. things in your software.</p>
  328. <h3><code>Makefile.in</code> file</h3>
  329. <p>Then, write a <code>Makefile.in</code> file. Basically, this is
  330. a very short <i>Makefile</i> that adds the name of the software to
  331. the list of <code>TARGETS</code> that Buildroot will generate. In
  332. fact, the name of the software is the the identifier of the target
  333. inside the real <i>Makefile</i> that will do everything (download,
  334. compile, install), and that we study below. Back to
  335. <code>Makefile.in</code>, here is an example :
  336. <pre>
  337. ifeq ($(strip $(BR2_PACKAGE_FOO)),y)
  338. TARGETS+=foo
  339. endif
  340. </pre>
  341. <p>As you can see, this short <i>Makefile</i> simply adds the
  342. target <code>foo</code> to the list of targets handled by Buildroot
  343. if software <i>foo</i> was selected using the configuration tool.</p>
  344. <h3>The real <i>Makefile</i></h3>
  345. <p>Finally, here's the hardest part. Create a file named
  346. <code>foo.mk</code>. It will contain the <i>Makefile</i> rules that
  347. are in charge of downloading, configuring, compiling and installing
  348. the software. Below is an example that we will comment
  349. afterwards.</p>
  350. <pre>
  351. 1 #############################################################
  352. 2 #
  353. 3 # foo
  354. 4 #
  355. 5 #############################################################
  356. 6 FOO_VERSION:=1.0
  357. 7 FOO_SOURCE:=less-$(FOO_VERSION).tar.gz
  358. 8 FOO_SITE:=http://www.foosoftware.org/downloads
  359. 9 FOO_DIR:=$(BUILD_DIR)/less-$(FOO_VERSION)
  360. 10 FOO_BINARY:=foo
  361. 11 FOO_TARGET_BINARY:=usr/bin/foo
  362. 12
  363. 13 $(DL_DIR)/$(FOO_SOURCE):
  364. 14 $(WGET) -P $(DL_DIR) $(FOO_SITE)/$(FOO_SOURCE)
  365. 15
  366. 16 $(FOO_DIR)/.source: $(DL_DIR)/$(FOO_SOURCE)
  367. 17 zcat $(DL_DIR)/$(FOO_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) -
  368. 18 touch $(FOO_DIR)/.source
  369. 19
  370. 20 $(FOO_DIR)/.configured: $(FOO_DIR)/.source
  371. 21 (cd $(FOO_DIR); \
  372. 22 $(TARGET_CONFIGURE_OPTS) \
  373. 23 CFLAGS="$(TARGET_CFLAGS)" \
  374. 24 ./configure \
  375. 25 --target=$(GNU_TARGET_NAME) \
  376. 26 --host=$(GNU_TARGET_NAME) \
  377. 27 --build=$(GNU_HOST_NAME) \
  378. 28 --prefix=/usr \
  379. 29 --sysconfdir=/etc \
  380. 30 );
  381. 31 touch $(FOO_DIR)/.configured;
  382. 32
  383. 33 $(FOO_DIR)/$(FOO_BINARY): $(FOO_DIR)/.configured
  384. 34 $(MAKE) CC=$(TARGET_CC) -C $(FOO_DIR)
  385. 35
  386. 36 $(TARGET_DIR)/$(FOO_TARGET_BINARY): $(FOO_DIR)/$(FOO_BINARY)
  387. 37 $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) install
  388. 38 rm -Rf $(TARGET_DIR)/usr/man
  389. 39
  390. 40 foo: uclibc ncurses $(TARGET_DIR)/$(FOO_TARGET_BINARY)
  391. 41
  392. 42 foo-source: $(DL_DIR)/$(FOO_SOURCE)
  393. 43
  394. 44 foo-clean:
  395. 45 $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) uninstall
  396. 46 -$(MAKE) -C $(FOO_DIR) clean
  397. 47
  398. 48 foo-dirclean:
  399. 49 rm -rf $(FOO_DIR)
  400. 50
  401. </pre>
  402. <p>First of all, this <i>Makefile</i> example works for a single
  403. binary software. For other softwares such as libraries or more
  404. complex stuff with multiple binaries, it should be adapted. Look at
  405. the other <code>*.mk</code> files in the <code>package</code>
  406. directory.</p>
  407. <p>At lines 6-11, a couple of useful variables are defined :</p>
  408. <ul>
  409. <li><code>FOO_VERSION</code> : The version of <i>foo</i> that
  410. should be downloaded.</li>
  411. <li><code>FOO_SOURCE</code> : The name of the tarball of
  412. <i>foo</i> on the download website of FTP site. As you can see
  413. <code>FOO_VERSION</code> is used.</li>
  414. <li><code>FOO_SITE</code> : The HTTP or FTP site from which
  415. <i>foo</i> archive is downloaded. It must include the complete
  416. path to the directory where <code>FOO_SOURCE</code> can be
  417. found.</li>
  418. <li><code>FOO_DIR</code> : The directory into which the software
  419. will be configured and compiled. Basically, it's a subdirectory
  420. of <code>BUILD_DIR</code> which is created upon decompression of
  421. the tarball.</li>
  422. <li><code>FOO_BINARY</code> : Software binary name. As said
  423. previously, this is an example for a single binary software.</li>
  424. <li><code>FOO_TARGET_BINARY</code> : The full path of the binary
  425. inside the target filesystem.</li>
  426. </ul>
  427. <p>Lines 13-14 defines a target that downloads the tarball from
  428. the remote site to the download directory
  429. (<code>DL_DIR</code>).</p>
  430. <p>Lines 16-18 defines a target and associated rules that
  431. uncompress the downloaded tarball. As you can see, this target
  432. depends on the tarball file, so that the previous target (line
  433. 13-14) is called before executing the rules of the current
  434. target. Uncompressing is followed by <i>touching</i> a hidden file
  435. to mark the software has having been uncompressed. This trick is
  436. used everywhere in Buildroot <i>Makefile</i> to split steps
  437. (download, uncompress, configure, compile, install) while still
  438. having correct dependencies.</p>
  439. <p>Lines 20-31 defines a target and associated rules that
  440. configures the software. It depends on the previous target (the
  441. hidden <code>.source</code> file) so that we are sure the software has
  442. been uncompressed. In order to configure it, it basically runs the
  443. well-known <code>./configure</code>script. As we may be doing
  444. cross-compilation, <code>target</code>, <code>host</code> and
  445. <code>build</code> arguments are given. The prefix is also set to
  446. <code>/usr</code>, not because the software will be installed in
  447. <code>/usr</code> on your host system, but in the target
  448. filesystem. Finally it creates a <code>.configured</code> file to
  449. mark the software as configured.</p>
  450. <p>Lines 33-34 defines a target and a rule that compiles the
  451. software. This target will create the binary file in the
  452. compilation directory, and depends on the software being already
  453. configured (hence the reference to the <code>.configured</code>
  454. file). It basically runs <code>make</code> inside the source
  455. directory.</p>
  456. <p>Lines 36-38 defines a target and associated rules that install
  457. the software inside the target filesystem. It depends on the
  458. binary file in the source directory, to make sure the software has
  459. been compiled. It uses the <code>install</code> target of the
  460. software <code>Makefile</code> by passing a <code>prefix</code>
  461. argument, so that the <code>Makefile</code> doesn't try to install
  462. the software inside host <code>/usr</code> but inside target
  463. <code>/usr</code>. After the installation, the
  464. <code>/usr/man</code> directory inside the target filesystem is
  465. removed to save space.</p>
  466. <p>Line 40 defines the main target of the software, the one
  467. referenced in the <code>Makefile.in</code> file. This targets
  468. should first of all depends on the dependecies of the software (in
  469. our example, <i>uclibc</i> and <i>ncurses</i>), and then to the
  470. final binary. This last dependency will call all previous
  471. dependencies in the right order. </p>
  472. <p>Line 42 defines a simple target that only downloads the code
  473. source. This is not used during normal operation of Buildroot, but
  474. might be useful.</p>
  475. <p>Lignes 44-46 define a simple target to clean the software build
  476. by calling the <i>Makefiles</i> with the appropriate option.</p>
  477. <p>Lines 48-49 define a simple target to completely remove the
  478. directory in which the software was uncompressed, configured and
  479. compiled.</p>
  480. <h3>Conclusion</h3>
  481. <p>As you can see, adding a software to buildroot is simply a
  482. matter of writing a <i>Makefile</i> using an already existing
  483. example and to modify it according to the compilation process of
  484. the software.</p>
  485. <p>If you package software that might be useful for other persons,
  486. don't forget to send a patch to Buildroot developers !</p>
  487. <h2><a name="links" id="links"></a>Ressources</h2>
  488. <p>To learn more about Buildroot you can visit these
  489. websites:</p>
  490. <ul>
  491. <li><a href="http://www.uclibc.org/">http://www.uclibc.org/</a></li>
  492. <li><a href="http://www.busybox.net/">http://www.busybox.net/</a></li>
  493. </ul>
  494. </div>
  495. </body>
  496. </html>