docs/buildroot.html

   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
   5 <html xmlns="http://www.w3.org/1999/xhtml">
   6 <head>
   7   <title>Buildroot - Usage and documentation</title>
   8   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
   9   <link rel="stylesheet" type="text/css" href="stylesheet.css" />
  10 </head>
  11
  12 <body>
  13   <div class="main">
  14     <div class="titre">
  15       <h1>Buildroot</h1>
  16     </div>
  17
  18     <p><a href="http://buildroot.uclibc.org/">Buildroot</a>
  19     usage and documentation by Thomas Petazzoni. Contributions from
  20     Karsten Kruse, Ned Ludd, Martin Herren and others. </p>
  21
  22     <p><small>$LastChangedDate: 2007-09-19 11:08:10 +0200 (Wed, 19 Sep 2007) $</small></p>
  23
  24     <ul>
  25
  26       <li><a href="#about">About Buildroot</a></li>
  27       <li><a href="#download">Obtaining Buildroot</a></li>
  28       <li><a href="#using">Using Buildroot</a></li>
  29       <li><a href="#custom_targetfs">Customizing the target filesystem</a></li>
  30       <li><a href="#custom_busybox">Customizing the Busybox
  31       configuration</a></li>
  32       <li><a href="#custom_uclibc">Customizing the uClibc
  33       configuration</a></li>
  34       <li><a href="#buildroot_innards">How Buildroot works</a></li>
  35       <li><a href="#using_toolchain">Using the uClibc toolchain</a></li>
  36       <li><a href="#toolchain_standalone">Using the uClibc toolchain
  37       outside of Buildroot</a></li>
  38       <li><a href="#downloaded_packages">Location of downloaded packages</a>
  39       </li>
  40       <li><a href="#add_software">Extending Buildroot with more
  41       Software</a></li>
  42       <li><a href="#links">Resources</a></li>
  43     </ul>
  44
  45     <h2><a name="about" id="about"></a>About Buildroot</h2>
  46
  47     <p>Buildroot is a set of Makefiles and patches that allow to easily
  48     generate both a cross-compilation toolchain and a root filesystem for your
  49     target. The cross-compilation toolchain uses uClibc (<a href=
  50     "http://www.uclibc.org/">http://www.uclibc.org/</a>), a tiny C standard
  51     library. </p>
  52
  53     <p>Buildroot is useful mainly for people working with embedded systems.
  54     Embedded systems often use processors that are not the regular x86
  55     processors everyone is used to have on his PC. It can be PowerPC
  56     processors, MIPS processors, ARM processors, etc. </p>
  57
  58     <p>A compilation toolchain is the set of tools that allows to
  59     compile code for your system. It consists of a compiler (in our
  60     case, <code>gcc</code>), binary utils like assembler and linker
  61     (in our case, <code>binutils</code>) and a C standard library (for
  62     example <a href="http://www.gnu.org/software/libc/libc.html">GNU
  63     Libc</a>, <a href="http://www.uclibc.org/">uClibc</a> or <a
  64     href="http://www.fefe.de/dietlibc/">dietlibc</a>). The system
  65     installed on your development station certainly already has a
  66     compilation toolchain that you can use to compile application that
  67     runs on your system. If you're using a PC, your compilation
  68     toolchain runs on an x86 processor and generates code for a x86
  69     processor. Under most Linux systems, the compilation toolchain
  70     uses the GNU libc as C standard library.  This compilation
  71     toolchain is called the &quot;host compilation toolchain&quot;, and more
  72     generally, the machine on which it is running, and on which you're
  73     working is called the &quot;host system&quot;. The compilation toolchain
  74     is provided by your distribution, and Buildroot has nothing to do
  75     with it. </p>
  76
  77     <p>As said above, the compilation toolchain that comes with your system
  78     runs and generates code for the processor of your host system. As your
  79     embedded system has a different processor, you need a cross-compilation
  80     toolchain: it's a compilation toolchain that runs on your host system but
  81     that generates code for your target system (and target processor). For
  82     example, if your host system uses x86 and your target system uses ARM, the
  83     regular compilation toolchain of your host runs on x86 and generates code
  84     for x86, while the cross-compilation toolchain runs on x86 and generates
  85     code for ARM. </p>
  86
  87     <p>Even if your embedded system uses a x86 processor, you might interested
  88     in Buildroot, for two reasons:</p>
  89
  90     <ul>
  91       <li>The compilation toolchain of your host certainly uses the GNU Libc
  92       which is a complete but huge C standard library. Instead of using GNU
  93       Libc on your target system, you can use uClibc which is a tiny C standard
  94       library. If you want to use this C library, then you need a compilation
  95       toolchain to generate binaries linked with it. Buildroot can do it for
  96       you. </li>
  97
  98       <li>Buildroot automates the building of a root filesystem with all needed
  99       tools like busybox. It makes it much easier than doing it by hand. </li>
 100     </ul>
 101
 102     <p>You might wonder why such a tool is needed when you can compile
 103     <code>gcc</code>, <code>binutils</code>, uClibc and all the tools by hand.
 104     Of course, doing so is possible. But dealing with all configure options,
 105     with all problems of every <code>gcc</code> or <code>binutils</code>
 106     version it very time-consuming and uninteresting. Buildroot automates this
 107     process through the use of Makefiles, and has a collection of patches for
 108     each <code>gcc</code> and <code>binutils</code> version to make them work
 109     on most architectures. </p>
 110
 111     <h2><a name="download" id="download"></a>Obtaining Buildroot</h2>
 112
 113     <p>Buildroot is available as daily SVN snapshots or directly using
 114     SVN. </p>
 115
 116     <p>The latest snapshot is always available at <a
 117     href="http://buildroot.uclibc.org/downloads/snapshots/buildroot-snapshot.tar.bz2">http://buildroot.uclibc.org/downloads/snapshots/buildroot-snapshot.tar.bz2</a>,
 118     and previous snapshots are also available at <a
 119     href="http://buildroot.uclibc.org/downloads/snapshots/">http://buildroot.uclibc.org/downloads/snapshots/</a>. </p>
 120
 121     <p>To download Buildroot using SVN, you can simply follow
 122     the rules described on the &quot;Accessing SVN&quot;-page (<a href=
 123     "http://buildroot.uclibc.org/subversion.html">http://buildroot.uclibc.org/subversion.html</a>)
 124     of the uClibc buildroot website (<a href=
 125     "http://buildroot.uclibc.org">http://buildroot.uclibc.org</a>), and download the
 126     <code>buildroot</code> SVN module. For the impatient, here's a quick
 127     recipe:</p>
 128
 129  <pre>
 130  $ svn co svn://uclibc.org/trunk/buildroot
 131 </pre>
 132
 133     <h2><a name="using" id="using"></a>Using Buildroot</h2>
 134
 135     <p>Buildroot has a nice configuration tool similar to the one you can find
 136     in the Linux Kernel (<a href=
 137     "http://www.kernel.org/">http://www.kernel.org/</a>) or in Busybox
 138     (<a href="http://www.busybox.org/">http://www.busybox.org/</a>). Note that
 139     you can build everything as a normal user. There is no need to be root to
 140     configure and use Buildroot. The first step is to run the configuration
 141     assistant:</p>
 142
 143 <pre>
 144  $ make menuconfig
 145 </pre>
 146
 147     <p>For each entry of the configuration tool, you can find associated help
 148     that describes the purpose of the entry. </p>
 149
 150     <p>One of the key configuration items is the <code>PROJECT</code> which
 151     determines where some board specific packages are built and where the
 152     results are stored. </p>
 153
 154     <p>Once everything is configured, the configuration tool has generated a
 155     <code>.config</code> file that contains the description of your
 156     configuration. It will be used by the Makefiles to do what's needed. </p>
 157
 158
 159     <p>Let's go:</p>
 160
 161 <pre>
 162  $ make
 163 </pre>
 164
 165     <p>This command will download, configure and compile all the selected
 166     tools, and finally generate a target filesystem. The target filesystem will
 167     be named <code>root_fs_ARCH.EXT</code> where <code>ARCH</code> is your
 168     architecture and <code>EXT</code> depends on the type of target filesystem
 169     selected in the <code>Target options</code> section of the configuration
 170     tool.
 171     The file is stored in the "binaries/<code>$(PROJECT)</code>/" directory</p>
 172
 173     <h3><a name="local_board_support" id="local_board_support"></a>
 174     Creating your own board support</h3>
 175
 176     <p>Once a package has been unpacked, it is possible to manually update
 177     configuration files. Buildroot can automatically save the configuration
 178     of buildroot, linux, busybox, uclibc and u-boot in "local/$(PROJECT) by
 179     using the command:
 180     </p>
 181
 182 <pre>
 183  $ make saveconfig
 184 </pre>
 185
 186      <p>Once a buildroot configuration has been created by saveconfig,
 187      the default "$(TOPDIR)/.config" file can be overridden by</p>
 188
 189 <pre>
 190  $ make BOARD=&lt;project&gt;
 191 </pre>
 192
 193     <p>Buildroot will then use "local/&lt;project&gt;/&lt;project&gt;.config"
 194     instead of ".config". </p>
 195
 196     <p>If you want to modify your board, you can copy the project configuration
 197      file to ".config" by using the command:</p>
 198
 199 <pre>
 200  $ make BOARD=&lt;project&gt; getconfig
 201 </pre>
 202
 203     <p>You can share your custom board support directory between several buildroot trees
 204     by setting the environment variable <code>BUILDROOT_LOCAL</code> to this directory,
 205     </p>
 206
 207
 208     <h3><a name="offline_builds" id="offline_builds"></a>
 209     Offline builds</h3>
 210
 211     <p>If you intend to do an offline-build and just want to download all
 212     sources that you previously selected in &quot;make menuconfig&quot; then
 213     issue:</p>
 214 <pre>
 215  $ make source
 216 </pre>
 217     <p>You can now disconnect or copy the content of your <code>dl</code>
 218     directory to the build-host. </p>
 219
 220     <h3><a name="environment_variables" id="environment_variables"></a>
 221     Environment variables</h3>
 222
 223     <p>Buildroot optionally honors some environment variables that are passed
 224     to <code>make</code> :</p>
 225     <ul>
 226     <li>HOSTCXX</li>
 227     <li>HOSTCC</li>
 228     <li>UCLIBC_CONFIG_FILE=&lt;path/to/.config&gt;</li>
 229     <li>BUSYBOX_CONFIG_FILE=&lt;path/to/.config&gt;</li>
 230     </ul>
 231
 232     <p>An example that uses config files located in the toplevel directory and
 233     in your $HOME:</p>
 234 <pre>
 235 $ make UCLIBC_CONFIG_FILE=uClibc.config BUSYBOX_CONFIG_FILE=$HOME/bb.config
 236 </pre>
 237
 238     <p>If you want to use a compiler other than the default <code>gcc</code>
 239     or <code>g++</code> for building helper-binaries on your host, then do</p>
 240 <pre>
 241 $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD
 242 </pre>
 243
 244     <h3><a name="helper_completion" id="helper_completion"></a>
 245     Using auto-completion</h3>
 246
 247     <p>If you are lazy enough that you don't want to type the entire <i>make
 248     menuconfig</i> command line, you can enable auto-completion in your shell.
 249     Here is how you can do that using <i>bash</i>:</p>
 250 <pre>
 251 $ complete -W menuconfig make
 252 </pre>
 253
 254     <p>Then just enter the beginning of the line, and ask <i>bash</i> to
 255     complete it for you by pressing the <i>TAB</i> key:</p>
 256 <pre>
 257 $ make me&lt;TAB&gt;
 258 </pre>
 259
 260     <p>will result in <i>bash</i> to append <i>nuconfig</i> for you!</p>
 261
 262     <p>Alternatively, some distributions (of which Debian and Mandriva are but
 263     an example) have more powerful make completion. Depending on you
 264     distribution, you may have to install a package to enable completion. Under
 265     Mandriva, this is <i>bash-completion</i>, while Debian ships it as part of
 266     the <i>bash</i> package.</p>
 267
 268     <p>Other shells, such as <i>zsh</i>, also have completion facilities. See
 269     the documentation for your shell.</p>
 270
 271     <h2><a name="custom_targetfs" id="custom_targetfs"></a>Customizing the
 272     target filesystem</h2>
 273
 274     <p>There are a few ways to customize the resulting target filesystem:</p>
 275
 276     <ul>
 277       <li>Customize the target filesystem directly, and rebuild the image. The
 278       target filesystem is available under <code>project_build_ARCH/root/</code>
 279       where <code>ARCH</code> is the chosen target architecture.
 280       You can simply make your changes here, and run make afterwards, which will
 281       rebuild the target filesystem image. This method allows to do everything
 282       on the target filesystem, but if you decide to completely rebuild your
 283       toolchain and tools, these changes will be lost. </li>
 284
 285       <li>Customize the target filesystem skeleton, available under
 286       <code>target/generic/target_skeleton/</code>. You can customize
 287       configuration files or other stuff here. However, the full file hierarchy
 288       is not yet present, because it's created during the compilation process.
 289       So you can't do everything on this target filesystem skeleton, but
 290       changes to it remain even if you completely rebuild the cross-compilation
 291       toolchain and the tools. <br />
 292       You can also customize the <code>target/generic/device_table.txt</code>
 293       file which is used by the tools that generate the target filesystem image
 294       to properly set permissions and create device nodes. The
 295       <code>target/generic/skel.tar.gz</code> file contains the main
 296       directories of a root filesystem and there is no obvious reason for which
 297       it should be changed. These main directories are in an tarball inside of
 298       inside the skeleton because it contains symlinks that would be broken
 299       otherwise. <br />
 300       These customizations are deployed into
 301       <code>project_build_ARCH/root/</code> just before the actual image
 302       is made. So simply rebuilding the image by running
 303       make should propagate any new changes to the image. </li>
 304
 305       <li>When configuring the build system, using <code>make menuconfig</code>,
 306       you can specify the contents of the /etc/hostname and /etc/issue
 307       (the welcome banner) in the <code>PROJECT</code> section</li>
 308     </ul>
 309
 310     <h2><a name="custom_busybox" id="custom_busybox"></a>Customizing the
 311     Busybox configuration</h2>
 312
 313     <p><a href="http://www.busybox.net/">Busybox</a> is very configurable, and
 314     you may want to customize it. You can
 315     follow these simple steps to do it. It's not an optimal way, but it's
 316     simple and it works. </p>
 317
 318     <ol>
 319       <li>Make a first compilation of buildroot with busybox without trying to
 320       customize it. </li>
 321
 322       <li>Invoke <code>make busybox-menuconfig</code>.
 323       The nice configuration tool appears and you can
 324       customize everything. </li>
 325
 326       <li>Run the compilation of buildroot again. </li>
 327     </ol>
 328
 329     <p>Otherwise, you can simply change the
 330     <code>package/busybox/busybox-&lt;version&gt;.config</code> file if you
 331     know the options you want to change without using the configuration tool.
 332     </p>
 333     <p>If you want to use an existing config file for busybox, then see
 334     section <a href="#environment_variables">environment variables</a>. </p>
 335
 336     <h2><a name="custom_uclibc" id="custom_uclibc"></a>Customizing the uClibc
 337     configuration</h2>
 338
 339     <p>Just like <a href="#custom_busybox">BusyBox</a>, <a
 340     href="http://www.uclibc.org/">uClibc</a> offers a lot of
 341     configuration options. They allow to select various
 342     functionalities, depending on your needs and limitations. </p>
 343
 344     <p>The easiest way to modify the configuration of uClibc is to
 345     follow these steps :</p>
 346
 347     <ol>
 348
 349       <li>Make a first compilation of buildroot without trying to
 350       customize uClibc. </li>
 351
 352       <li>Invoke <code>make uclibc-menuconfig</code>.
 353       The nice configuration assistant, similar to
 354       the one used in the Linux Kernel or in Buildroot appears. Make
 355       your configuration as appropriate. </li>
 356
 357       <li>Copy the <code>.config</code> file to
 358       <code>toolchain/uClibc/uClibc.config</code> or
 359       <code>toolchain/uClibc/uClibc.config-locale</code>. The former
 360       is used if you haven't selected locale support in Buildroot
 361       configuration, and the latter is used if you have selected
 362       locale support. </li>
 363
 364       <li>Run the compilation of Buildroot again</li>
 365
 366     </ol>
 367
 368     <p>Otherwise, you can simply change
 369     <code>toolchain/uClibc/uClibc.config</code> or
 370     <code>toolchain/uClibc/uClibc.config-locale</code> without running
 371     the configuration assistant. </p>
 372
 373     <p>If you want to use an existing config file for uclibc, then see
 374     section <a href="#environment_variables">environment variables</a>. </p>
 375
 376     <h2><a name="buildroot_innards" id="buildroot_innards"></a>How Buildroot
 377     works</h2>
 378
 379     <p>As said above, Buildroot is basically a set of Makefiles that download,
 380     configure and compiles software with the correct options. It also includes
 381     some patches for various software, mainly the ones involved in the
 382     cross-compilation tool chain (<code>gcc</code>, <code>binutils</code> and
 383     uClibc). </p>
 384
 385     <p>There is basically one Makefile per software, and they are named with
 386     the <code>.mk</code> extension. Makefiles are split into four
 387     sections:</p>
 388
 389     <ul>
 390       <li><b>project</b> (in the <code>project/</code> directory) contains
 391       the Makefiles and associated files for all software related to the
 392       building several root file systems in the same buildroot tree. </li>
 393
 394       <li><b>toolchain</b> (in the <code>toolchain/</code> directory) contains
 395       the Makefiles and associated files for all software related to the
 396       cross-compilation toolchain : <code>binutils</code>, <code>ccache</code>,
 397       <code>gcc</code>, <code>gdb</code>, <code>kernel-headers</code> and
 398       <code>uClibc</code>. </li>
 399
 400       <li><b>package</b> (in the <code>package/</code> directory) contains the
 401       Makefiles and associated files for all user-space tools that Buildroot
 402       can compile and add to the target root filesystem. There is one
 403       sub-directory per tool. </li>
 404
 405       <li><b>target</b> (in the <code>target</code> directory) contains the
 406       Makefiles and associated files for software related to the generation of
 407       the target root filesystem image. Four types of filesystems are supported
 408       : ext2, jffs2, cramfs and squashfs. For each of them, there's a
 409       sub-directory with the required files. There is also a
 410       <code>default/</code> directory that contains the target filesystem
 411       skeleton. </li>
 412     </ul>
 413
 414     <p>Each directory contains at least 2 files :</p>
 415
 416     <ul>
 417       <li><code>something.mk</code> is the Makefile that downloads, configures,
 418       compiles and installs the software <code>something</code>. </li>
 419
 420       <li><code>Config.in</code> is a part of the configuration tool
 421       description file. It describes the option related to the current
 422       software. </li>
 423
 424     </ul>
 425
 426     <p>The main Makefile do the job through the following steps (once the
 427     configuration is done):</p>
 428
 429     <ol>
 430       <li>Create the download directory (<code>dl/</code> by default). This is
 431       where the tarballs will be downloaded. It is interesting to know that the
 432       tarballs are in this directory because it may be useful to save them
 433       somewhere to avoid further downloads. </li>
 434
 435       <li>Create the shared build directory (<code>build_ARCH/</code> by
 436       default, where <code>ARCH</code> is your architecture). This is where all
 437       non configurable user-space tools will be compiled.When building two or
 438       more targets using the same architecture, the first build will go through
 439       the full download, configure, make process, but the second and later
 440       builds will only copy the result from the first build to its project
 441       specific target directory significantly speeding up the build process</li>
 442
 443       <li>Create the project specific build directory
 444       (<code>project_build_ARCH/$(PROJECT)</code> by default, where
 445       <code>ARCH</code> is your architecture). This is where all configurable
 446       user-space tools will be compiled. The project specific build directory
 447       is neccessary, if two different targets needs to use a specific package,
 448       but the packages have different configuration for both targets. Some
 449       examples of packages built in this directory are busybox and linux.
 450       </li>
 451
 452       <li>Create the project specific result directory
 453       (<code>binaries/$(PROJECT)</code> by default, where <code>ARCH</code>
 454       is your architecture). This is where the root filesystem images are
 455       stored, It is also used to store the linux kernel image and any
 456       utilities, boot-loaders etc. needed for a target.
 457       </li>
 458
 459       <li>Create the toolchain build directory
 460       (<code>toolchain_build_ARCH/</code> by default, where <code>ARCH</code>
 461       is your architecture). This is where the cross compilation toolchain will
 462       be compiled. </li>
 463
 464       <li>Setup the staging directory (<code>build_ARCH/staging_dir/</code> by
 465       default). This is where the cross-compilation toolchain will be
 466       installed. If you want to use the same cross-compilation toolchain for
 467       other purposes, such as compiling third-party applications, you can add
 468       <code>build_ARCH/staging_dir/usr/bin</code> to your PATH, and then use
 469       <code>arch-linux-gcc</code> to compile your application. In order to
 470       setup this staging directory, it first removes it, and then it creates
 471       various subdirectories and symlinks inside it. </li>
 472
 473       <li>Create the target directory (<code>project_build_ARCH/root/</code> by
 474       default) and the target filesystem skeleton. This directory will contain
 475       the final root filesystem. To setup it up, it first deletes it, then it
 476       uncompress the <code>target/generic/skel.tar.gz</code> file to create the
 477       main subdirectories and symlinks, copies the skeleton available in
 478       <code>target/generic/target_skeleton</code> and then removes useless
 479       <code>.svn/</code> directories. </li>
 480
 481       <li>Add the <code>TARGETS</code> dependency. This should generally check
 482       if the configuration option for this package is enabled, and if so then
 483       &quot;subscribe&quot; this package to be compiled by adding it to the
 484       TARGETS global variable. </li>
 485     </ol>
 486
 487     <h2><a name="multi_project" id="multi_project"></a>Building several
 488       projects in the same buildroot source tree</h2>
 489
 490     <p><b>BACKGROUND</b></p>
 491
 492     <p>Buildroot has always supported building several projects in the same
 493     tree if each project was for a different architecture. </p>
 494
 495     <p>The root file system has been created in the
 496     <code>&quot;build_&lt;ARCH&gt;/root&quot;</code>
 497     directory which is unique for each architecture.
 498     Toolchains have been built in
 499     <code>&quot;toolchain_build_&lt;ARCH&gt;&quot;</code>. </p>
 500
 501     <p> It the user wanted to build several root file systems for the same
 502     architecture, a prefix or suffix could be added in the configuration file
 503     so the root file system would be built in
 504     <code>&quot;&lt;PREFIX&gt;_build_&lt;ARCH&gt;_&lt;SUFFIX&gt;/root&quot;</code>
 505     By supplying <u>unique</u> combinations of
 506     <code>&quot;&lt;PREFIX&gt;&quot;</code> and
 507     <code>&quot;&lt;SUFFIX&gt;&quot;</code>
 508     each project would get a <u>unique</u> root file system tree. </p>
 509
 510     <p>The disadvantage of this approach is that a new toolchain was
 511     built for each project,  adding considerable time to the build
 512     process, even if it was two projects for the same chip. </p>
 513
 514     <p>This drawback has been somewhat lessened with
 515     <code>gcc-4.x.y</code> which allows buildroot to use an external
 516     toolchain. Certain packages requires special
 517     features in the toolchain, and if an external toolchain is selected,
 518     this may lack the neccessary features to complete the build of the root
 519      file system.</p>
 520
 521     <p>A bigger problem was that the
 522     <code>&quot;build_&lt;ARCH&gt;&quot;</code> tree
 523     was also duplicated, so each </code>package</code> would also
 524     be rebuilt once per project, resulting in even longer build times.</p>
 525
 526
 527     <p><b>PROJECT TO SHARE TOOLCHAIN AND PACKAGE BUILDS</b></p>
 528
 529     <p>Work has started on a project which will allow the user to build
 530     multiple root file systems for the same architecture in the same tree.
 531     The toolchain and the package build directory will be shared, but each
 532     project will have a dedicated directory tree for project specific
 533     builds. </p>
 534
 535     <p>With this approach, most, if not all packages will be compiled
 536     when the first project is built.
 537     The process is almost identical to the original process.
 538     Packages are downloaded and extracted to the shared
 539     <code>&quot;build_&lt;ARCH&gt;/&lt;package&gt;&quot;</code>
 540     directory. They are configured and compiled. </p>
 541
 542     <p>Package libraries and headers are installed in the shared $(STAGING_DIR),
 543     and then the project specific root file system &quot;$(TARGET_DIR)&quot;
 544     is populated. </p>
 545
 546     <p>At the end of the build, the root file system will be used
 547     to generate the resulting root file system binaries. </p>
 548
 549     <p>Once the first project has been built, building other projects will
 550     typically involve populating the new project's root file system directory
 551     from the existing binaries generated in the shared
 552     <code>&quot;build_&lt;ARCH&gt;/&lt;&gt;&quot;</code> directory. </p>
 553
 554     <p>Only packages, not used by the first project, will have to go
 555     through the normal extract-configure-compile flow. </p>
 556
 557     <p><b>IMPLEMENTATION</b></p>
 558
 559     <p>The core of the solution is the introduction
 560     of two new directories: </p>
 561
 562     <ul>
 563     <li><code>project_build_&lt;ARCH&gt;</code></li>
 564
 565     <li><code>binaries;</code></li>
 566     </ul>
 567
 568     <p>Each of the directories contain one subdirectory per project.
 569     The name of the subdirectory is configured by the user in the
 570     normal buildroot configuration, using the value of: </p>
 571
 572     <p><code>Project Options ---> Project name</code></p>
 573
 574     <p>The configuration defines the $(PROJECT) variable.</p>
 575
 576     <p>The default project name is <code>&quot;uclibc&quot;</code>.</p>
 577
 578     <p><code>&quot;package/Makefile.in&quot;</code> defines:
 579     <pre>
 580     <code>PROJECT_BUILD_DIR:=project_build_$(ARCH)/$(PROJECT)</code>
 581     <code>BINARIES_DIR:=binaries/$(PROJECT)</code>
 582     </pre>
 583     </p>
 584
 585     <p>It also defines the location for the target root file system:
 586     <pre>
 587     <code>TARGET_DIR:=$(PROJECT_BUILD_DIR)/$(PROJECT)/root</code>
 588     </pre>
 589     </p>
 590
 591     <p>I.E: If the user has choosen
 592     <code>&quot;myproject&quot;</code>
 593     as the $(PROJECT) name:
 594
 595     <ul>
 596     <li><code>&quot;project_build_&lt;ARCH&gt;/myproject&quot;</code></li>
 597     <li><code>&quot;binaries/myproject&quot;</code></li>
 598     </ul>
 599
 600     <p>will be created. </p>
 601
 602     <p>Currently, the <u>root file system</u>, <u>busybox</u> and an Atmel
 603     customized version of
 604     <u><code>U-Boot</code></u>, as well as some Atmel specific
 605     bootloaders like <u>at91-bootstrap</u> and <u>dataflashboot.bin</u>
 606     are built in
 607     <code>&quot;$(PROJECT_BUILD_DIR)&quot;</code>
 608
 609     <p>The resulting binaries for all architectures are stored in the
 610     <code>&quot;$(BINARIES_DIR)&quot;</code> directory. <p>
 611
 612     <p><b>SUMMARY</b></p>
 613
 614     <p>The project will share directories which can be share without
 615     conflicts, but will use unique build directories, where the user
 616     can configure the build. </p>
 617
 618     <p><b>THINGS TO DO</b></p>
 619
 620     <ol>
 621
 622     <li>Linux</li>
 623
 624     <p>The current Linux implementation is flawed. It only works
 625     if the user chooses to use one of the few kernels selected
 626     as base for the kernel-headers. While the Makefile seems to have
 627     hooks, allowing the developer to specify whatever version he/she
 628     wants in the target/device/*/* Makefiles, the build will fail
 629     if another kernel version is choosen.</p>
 630
 631     <p>The reason for this is that the kernel patches are not
 632     applied by the <code>&quot;target/linux/linux.mk&quot;</code>
 633     build script fragment. They are only applied by the
 634     <code>&quot;toolchain/kernel-headers/*.makefile&quot;</code>
 635     build script fragments</p>
 636
 637     <p>If the kernel-header version and the linux version differs,
 638     there will be two <code>&quot;linux-2.6.X.Y&quot;</code>
 639     directories in
 640     <code>&quot;build_&lt;ARCH&gt;/&lt;&gt;&quot;</code>,
 641     each with its own set of patches. </p>
 642
 643     <p>The solution in the works, is to move the build of Linux to
 644     <code>&quot;project_build_&lt;ARCH&gt;/&lt;project name&gt;/linux-2.6.X.Y&quot;</code> combined with method to configure
 645      which patches can be applied. Possibly, the linux source tree
 646      used to generate the kernel headers will be moved to the
 647      <code>&quot;toolchain_build_&lt;ARCH&gt;&quot;</code>
 648      directory
 649       </p>
 650
 651      <p>The user will be able to select from three different
 652      Linux strategies:
 653
 654      <ul>
 655      <li>Conservative Strategy: Only use version ssupported by the kernel headers</li>
 656      <li>Stable Linux Strategy: Allow any 2.6.X.Y combination.
 657         (Minimum 2.6.19)</li>
 658      <li>Power-User Strategy: Allow
 659      <code>&quot;-git&quot;</code>, or
 660      <code>&quot;-mm&quot;</code>, or user downloadable kernels</li>
 661      </ul>
 662
 663      <p>The current kernel patches can be configured to be applied to the
 664      linux source tree even if the version differs from the
 665      kernel header version. </p>
 666
 667      <p>Since the user can select any kernel-patch
 668      he/she will be able to select a non-working combination.
 669      If the patch fails, the user will have to generate a new
 670      proprietary kernel-patch or decide to not apply the kernel
 671      patches</p>
 672
 673      <p>Other optional patches will be <u>board specific</u> or
 674      <u>architecture specific</u> patches. </p>
 675
 676      <p>There will also be a way for the user to supply absolute
 677      or relative paths to patches, possibly outside the main tree.
 678      This can be used to apply custom kernel-header-patches, if
 679      the versions available in buildroot cannot be applied to the
 680      specific linux version used</p>
 681
 682      <p>Maybe, there will also be a possibility to supply an
 683      <code>&quot;URL&quot;</code> to a patch available on Internet. </p>
 684
 685      <li>Configurable packages</li>
 686
 687      <p>Many packages can, on top of the simple
 688      &quot;enable/disable build&quot;,
 689      be further configured using Kconfig.
 690      Currently these packages will be compiled using the
 691      configuration specified in the
 692      <code>&quot;.config&quot;</code> file of the <u>first</u>
 693      project demanding the build of the package.</p>
 694
 695      <p>If <u>another</u> project uses the same packages, but with
 696      a different configuration,these packages will <u>not</u> be rebuilt,
 697      and the root file system for the new project will be populated
 698      with files from the build of the <u>first</u> project</p>
 699
 700      <p>If multiple project are built, and a specific package
 701      needs two different configuration, then the user must
 702      delete the package from the
 703      <code>&quot;build_&lt;ARCH&gt;&quot;</code> directory
 704      before rebuilding the new project.<p>
 705
 706      <p>A long term solution is to edit the package makefile and move
 707      the build of the configurable packages from
 708      <code>&quot;build_&lt;ARCH&gt;&quot;</code> to
 709      <code>&quot;project_build_&lt;ARCH&gt;/&lt;project name&gt;&quot;</code>
 710      and send a patch to the buildroot mailing list.
 711
 712      <li>Naming conventions</li>
 713
 714      <p>Names of resulting binaries should reflect the
 715      &quot;project name&quot;
 716
 717      <li>Generating File System binaries</li>
 718      <p>
 719      Packages which needs to be installed with the &quot;root&quot;
 720      as owner, will generate a
 721      <code>&quot;.fakeroot.&lt;package&gt;&quot;</code> file
 722      which will be used for the final build of the root file system binary. </p>
 723
 724      <p>This was previously located in the
 725      <code>&quot;$(STAGING_DIR)&quot;</code> directory, but was
 726      recently moved to the
 727      <code>&quot;$(PROJECT_BUILD_DIR)&quot;</code> directory. </p>
 728
 729      <p>Currently only three packages:
 730      <code>&quot;at&quot;</code>,
 731      <code>&quot;ltp-testsuite&quot;</code> and
 732      <code>&quot;nfs-utils&quot;</code>
 733      requests fakeroot. <p>
 734
 735      <p>The makefile fragments for each file system type like
 736      <code>&quot;ext2&quot;</code>,
 737      <code>&quot;jffs2&quot;</code> or
 738      <code>&quot;squashfs&quot;</code>
 739      will, when the file system binary is generated,
 740      collect all present
 741      <code>&quot;.fakeroot.&lt;package&gt;&quot;</code> files
 742      to a single <code>&quot;_fakeroot.&lt;file system&gt;&quot;</code>
 743      file and call fakeroot.</p>
 744      <code>&quot;.fakeroot.&lt;package&gt;&quot;</code>
 745      files are deleted as the last action of the Buildroot Makefile. </p>
 746
 747      <p>It needs to be evaluated if any further action for the
 748      file system binary build is needed. </p>
 749
 750      </ol>
 751
 752     <h2><a name="using_toolchain" id="using_toolchain"></a>Using the
 753     uClibc toolchain</h2>
 754
 755     <p>You may want to compile your own programs or other software
 756     that are not packaged in Buildroot. In order to do this, you can
 757     use the toolchain that was generated by Buildroot. </p>
 758
 759     <p>The toolchain generated by Buildroot by default is located in
 760     <code>build_ARCH/staging_dir/</code>. The simplest way to use it
 761     is to add <code>build_ARCH/staging_dir/usr/bin/</code> to your PATH
 762     environnement variable, and then to use
 763     <code>arch-linux-gcc</code>, <code>arch-linux-objdump</code>,
 764     <code>arch-linux-ld</code>, etc. </p>
 765
 766     <p>For example, you may add the following to your
 767     <code>.bashrc</code> (considering you're building for the MIPS
 768     architecture and that Buildroot is located in
 769     <code>~/buildroot/</code>) :</p>
 770
 771 <pre>
 772 export PATH=&quot;$PATH:~/buildroot/build_mips/staging_dir/usr/bin/&quot;
 773 </pre>
 774
 775     <p>Then you can simply do :</p>
 776
 777 <pre>
 778 mips-linux-gcc -o foo foo.c
 779 </pre>
 780
 781     <p><b>Important</b> : do not try to move a gcc-3.x toolchain to an other
 782     directory, it won't work. There are some hardcoded paths in the
 783     <i>gcc</i> configuration. If the default toolchain directory
 784     doesn't suit your needs, please refer to the <a
 785     href="#toolchain_standalone">Using the uClibc toolchain outside of
 786     buildroot</a> section. </p>
 787     <p>If you are using a current gcc-4.x, then use --sysroot and -isysroot
 788     since these toolchains have fully functional sysroot support. No
 789     hardcoded paths do exist in these configurations. </p>
 790
 791     <h2><a name="toolchain_standalone" id="toolchain_standalone"></a>Using the
 792     uClibc toolchain outside of buildroot</h2>
 793
 794     <p>By default, the cross-compilation toolchain is generated inside
 795     <code>build_ARCH/staging_dir/</code>. But sometimes, it may be useful to
 796     install it somewhere else, so that it can be used to compile other programs
 797     or by other users. Moving the <code>build_ARCH/staging_dir/</code>
 798     directory elsewhere is <b>not possible if using gcc-3.x</b>, because there
 799     are some hardcoded paths in the toolchain configuration. This works, thanks
 800     to sysroot support, with current, stable gcc-4.x toolchains, of course. </p>
 801
 802     <p>If you want to use the generated gcc-3.x toolchain for other purposes,
 803     you can configure Buildroot to generate it elsewhere using the
 804     option of the configuration tool : <code>Build options -&gt;
 805     Toolchain and header file location</code>, which defaults to
 806     <code>$(BUILD_DIR)/staging_dir/</code>. </p>
 807
 808     <h2><a name="downloaded_packages"
 809     id="downloaded_packages"></a>Location of downloaded packages</h2>
 810
 811     <p>It might be useful to know that the various tarballs that are
 812     downloaded by the <i>Makefiles</i> are all stored in the
 813     <code>DL_DIR</code> which by default is the <code>dl</code>
 814     directory. It's useful for example if you want to keep a complete
 815     version of Buildroot which is know to be working with the
 816     associated tarballs. This will allow you to regenerate the
 817     toolchain and the target filesystem with exactly the same
 818     versions. </p>
 819
 820     <p>If you maintain several buildroot trees, it might be better to have
 821     a shared download location. This can be accessed by creating a symbolic link
 822     from the <code>dl</code> directory to the shared download location. </p>
 823
 824     <p>I.E:</p>
 825
 826 <pre>
 827 ln -s &lt;shared download location&gt; dl
 828 </pre>
 829
 830     <p>Another way of accessing a shared download location is to
 831     create the <code>BUILDROOT_DL_DIR</code> environment variable.
 832     If this is set, then the value of DL_DIR in the project is
 833     overridden. The following line should be added to
 834     <code>&quot;~/.bashrc&quot;</code>. <p>
 835
 836 <pre>
 837 export BUILDROOT_DL_DIR &lt;shared download location&gt;
 838 </pre>
 839
 840
 841
 842     <h2><a name="add_software" id="add_software"></a>Extending Buildroot with
 843     more software</h2>
 844
 845     <p>This section will only consider the case in which you want to
 846     add user-space software. </p>
 847
 848     <h3>Package directory</h3>
 849
 850     <p>First of all, create a directory under the <code>package</code>
 851     directory for your software, for example <code>foo</code>. </p>
 852
 853     <h3><code>Config.in</code> file</h3>
 854
 855     <p>Then, create a file named <code>Config.in</code>. This file
 856     will contain the portion of options description related to our
 857     <code>foo</code> software that will be used and displayed in the
 858     configuration tool. It should basically contain :</p>
 859
 860 <pre>
 861 config BR2_PACKAGE_FOO
 862         bool "foo"
 863         default n
 864         help
 865           This is a comment that explains what foo is.
 866
 867           http://foosoftware.org/foo/
 868 </pre>
 869
 870     <p>Of course, you can add other options to configure particular
 871     things in your software. </p>
 872
 873    <h3>The real <i>Makefile</i></h3>
 874
 875    <p>Finally, here's the hardest part. Create a file named
 876    <code>foo.mk</code>. It will contain the <i>Makefile</i> rules that
 877    are in charge of downloading, configuring, compiling and installing
 878    the software. Below is an example that we will comment
 879    afterwards. </p>
 880
 881 <pre>
 882      <a name="line1" id="line1">1</a>  #############################################################
 883      <a name="line2" id="line2">2</a>  #
 884      <a name="line3" id="line3">3</a>  # foo
 885      <a name="line4" id="line4">4</a>  #
 886      <a name="line5" id="line5">5</a>  #############################################################
 887      <a name="line6" id="line6">6</a>  FOO_VERSION:=1.0
 888      <a name="line7" id="line7">7</a>  FOO_SOURCE:=foo-$(FOO_VERSION).tar.gz
 889      <a name="line8" id="line8">8</a>  FOO_SITE:=http://www.foosoftware.org/downloads
 890      <a name="line9" id="line9">9</a>  FOO_DIR:=$(BUILD_DIR)/foo-$(FOO_VERSION)
 891     <a name="line10" id="line10">10</a>  FOO_BINARY:=foo
 892     <a name="line11" id="line11">11</a>  FOO_TARGET_BINARY:=usr/bin/foo
 893     <a name="line12" id="line12">12</a>
 894     <a name="line13" id="line13">13</a>  $(DL_DIR)/$(FOO_SOURCE):
 895     <a name="line14" id="line14">14</a>          $(WGET) -P $(DL_DIR) $(FOO_SITE)/$(FOO_SOURCE)
 896     <a name="line15" id="line15">15</a>
 897     <a name="line16" id="line16">16</a>  $(FOO_DIR)/.source: $(DL_DIR)/$(FOO_SOURCE)
 898     <a name="line17" id="line17">17</a>          $(ZCAT) $(DL_DIR)/$(FOO_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) -
 899     <a name="line18" id="line18">18</a>          touch $@
 900     <a name="line19" id="line19">19</a>
 901     <a name="line20" id="line20">20</a>  $(FOO_DIR)/.configured: $(FOO_DIR)/.source
 902     <a name="line21" id="line21">21</a>          (cd $(FOO_DIR); rm -rf config.cache; \
 903     <a name="line22" id="line22">22</a>                  $(TARGET_CONFIGURE_OPTS) \
 904     <a name="line23" id="line23">23</a>                  $(TARGET_CONFIGURE_ARGS) \
 905     <a name="line24" id="line24">24</a>                  ./configure \
 906     <a name="line25" id="line25">25</a>                  --target=$(GNU_TARGET_NAME) \
 907     <a name="line26" id="line26">26</a>                  --host=$(GNU_TARGET_NAME) \
 908     <a name="line27" id="line27">27</a>                  --build=$(GNU_HOST_NAME) \
 909     <a name="line28" id="line28">28</a>                  --prefix=/usr \
 910     <a name="line29" id="line29">29</a>                  --sysconfdir=/etc \
 911     <a name="line30" id="line30">30</a>          )
 912     <a name="line31" id="line31">31</a>          touch $@
 913     <a name="line32" id="line32">32</a>
 914     <a name="line33" id="line33">33</a>  $(FOO_DIR)/$(FOO_BINARY): $(FOO_DIR)/.configured
 915     <a name="line34" id="line34">34</a>          $(MAKE) CC=$(TARGET_CC) -C $(FOO_DIR)
 916     <a name="line35" id="line35">35</a>
 917     <a name="line36" id="line36">36</a>  $(TARGET_DIR)/$(FOO_TARGET_BINARY): $(FOO_DIR)/$(FOO_BINARY)
 918     <a name="line37" id="line37">37</a>          $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) install
 919     <a name="line38" id="line38">38</a>          rm -Rf $(TARGET_DIR)/usr/man
 920     <a name="line39" id="line39">39</a>
 921     <a name="line40" id="line40">40</a>  foo: uclibc ncurses $(TARGET_DIR)/$(FOO_TARGET_BINARY)
 922     <a name="line41" id="line41">41</a>
 923     <a name="line42" id="line42">42</a>  foo-source: $(DL_DIR)/$(FOO_SOURCE)
 924     <a name="line43" id="line43">43</a>
 925     <a name="line44" id="line44">44</a>  foo-clean:
 926     <a name="line45" id="line45">45</a>          $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) uninstall
 927     <a name="line46" id="line46">46</a>          -$(MAKE) -C $(FOO_DIR) clean
 928     <a name="line47" id="line47">47</a>
 929     <a name="line48" id="line48">48</a>  foo-dirclean:
 930     <a name="line49" id="line49">49</a>          rm -rf $(FOO_DIR)
 931     <a name="line50" id="line50">50</a>
 932     <a name="line51" id="line51">51</a> #############################################################
 933     <a name="line52" id="line52">52</a> #
 934     <a name="line53" id="line53">53</a> # Toplevel Makefile options
 935     <a name="line54" id="line54">54</a> #
 936     <a name="line55" id="line55">55</a> #############################################################
 937     <a name="line56" id="line56">56</a> ifeq ($(strip $(BR2_PACKAGE_FOO)),y)
 938     <a name="line57" id="line57">57</a> TARGETS+=foo
 939     <a name="line58" id="line58">58</a> endif
 940
 941 </pre>
 942
 943     <p>First of all, this <i>Makefile</i> example works for a single
 944     binary software. For other software such as libraries or more
 945     complex stuff with multiple binaries, it should be adapted. Look at
 946     the other <code>*.mk</code> files in the <code>package</code>
 947     directory. </p>
 948
 949     <p>At lines <a href="#line6">6-11</a>, a couple of useful variables are
 950     defined :</p>
 951
 952     <ul>
 953
 954      <li><code>FOO_VERSION</code> : The version of <i>foo</i> that
 955      should be downloaded. </li>
 956
 957      <li><code>FOO_SOURCE</code> : The name of the tarball of
 958      <i>foo</i> on the download website of FTP site. As you can see
 959      <code>FOO_VERSION</code> is used. </li>
 960
 961      <li><code>FOO_SITE</code> : The HTTP or FTP site from which
 962      <i>foo</i> archive is downloaded. It must include the complete
 963      path to the directory where <code>FOO_SOURCE</code> can be
 964      found. </li>
 965
 966      <li><code>FOO_DIR</code> : The directory into which the software
 967      will be configured and compiled. Basically, it's a subdirectory
 968      of <code>BUILD_DIR</code> which is created upon decompression of
 969      the tarball. </li>
 970
 971      <li><code>FOO_BINARY</code> : Software binary name. As said
 972      previously, this is an example for a single binary software. </li>
 973
 974      <li><code>FOO_TARGET_BINARY</code> : The full path of the binary
 975      inside the target filesystem. </li>
 976
 977     </ul>
 978
 979     <p>Lines <a href="#line13">13-14</a> defines a target that downloads the
 980     tarball from the remote site to the download directory
 981     (<code>DL_DIR</code>). </p>
 982
 983     <p>Lines <a href="#line16">16-18</a> defines a target and associated rules
 984     that uncompress the downloaded tarball. As you can see, this target
 985     depends on the tarball file, so that the previous target (line
 986     <a href="#line13">13-14</a>) is called before executing the rules of the
 987     current target. Uncompressing is followed by <i>touching</i> a hidden file
 988     to mark the software has having been uncompressed. This trick is
 989     used everywhere in Buildroot <i>Makefile</i> to split steps
 990     (download, uncompress, configure, compile, install) while still
 991     having correct dependencies. </p>
 992
 993     <p>Lines <a href="#line20">20-31</a> defines a target and associated rules
 994     that configures the software. It depends on the previous target (the
 995     hidden <code>.source</code> file) so that we are sure the software has
 996     been uncompressed. In order to configure it, it basically runs the
 997     well-known <code>./configure</code> script. As we may be doing
 998     cross-compilation, <code>target</code>, <code>host</code> and
 999     <code>build</code> arguments are given. The prefix is also set to
1000     <code>/usr</code>, not because the software will be installed in
1001     <code>/usr</code> on your host system, but in the target
1002     filesystem. Finally it creates a <code>.configured</code> file to
1003     mark the software as configured. </p>
1004
1005     <p>Lines <a href="#line33">33-34</a> defines a target and a rule that
1006     compiles the software. This target will create the binary file in the
1007     compilation directory, and depends on the software being already
1008     configured (hence the reference to the <code>.configured</code>
1009     file). It basically runs <code>make</code> inside the source
1010     directory. </p>
1011
1012     <p>Lines <a href="#line36">36-38</a> defines a target and associated rules
1013     that install the software inside the target filesystem. It depends on the
1014     binary file in the source directory, to make sure the software has
1015     been compiled. It uses the <code>install</code> target of the
1016     software <code>Makefile</code> by passing a <code>prefix</code>
1017     argument, so that the <code>Makefile</code> doesn't try to install
1018     the software inside host <code>/usr</code> but inside target
1019     <code>/usr</code>. After the installation, the
1020     <code>/usr/man</code> directory inside the target filesystem is
1021     removed to save space. </p>
1022
1023     <p>Line <a href="#line40">40</a> defines the main target of the software,
1024     the one that will be eventually be used by the top level
1025     <code>Makefile</code> to download, compile, and then install
1026     this package. This target should first of all depends on all
1027     needed dependecies of the software (in our example,
1028     <i>uclibc</i> and <i>ncurses</i>), and also depend on the
1029     final binary. This last dependency will call all previous
1030     dependencies in the correct order. </p>
1031
1032     <p>Line <a href="#line42">42</a> defines a simple target that only
1033     downloads the code source. This is not used during normal operation of
1034     Buildroot, but is needed if you intend to download all required sources at
1035     once for later offline build. Note that if you add a new package providing
1036     a <code>foo-source</code> target is <i>mandatory</i> to support
1037     users that wish to do offline-builds. Furthermore it eases checking
1038     if all package-sources are downloadable. </p>
1039
1040     <p>Lines <a href="#line44">44-46</a> define a simple target to clean the
1041     software build by calling the <i>Makefiles</i> with the appropriate option.
1042     The <code>-clean</code> target should run <code>make clean</code>
1043     on $(BUILD_DIR)/package-version and MUST uninstall all files of the
1044     package from $(STAGING_DIR) and from $(TARGET_DIR). </p>
1045
1046     <p>Lines <a href="#line48">48-49</a> define a simple target to completely
1047     remove the directory in which the software was uncompressed, configured and
1048     compiled. The <code>-dirclean</code> target MUST completely rm $(BUILD_DIR)/
1049     package-version. </p>
1050
1051     <p>Lines <a href="#line51">51-58</a> adds the target <code>foo</code> to
1052     the list of targets to be compiled by Buildroot by first checking if
1053     the configuration option for this package has been enabled
1054     using the configuration tool, and if so then &quot;subscribes&quot;
1055     this package to be compiled by adding it to the TARGETS
1056     global variable.  The name added to the TARGETS global
1057     variable is the name of this package's target, as defined on
1058     line <a href="#line40">40</a>, which is used by Buildroot to download,
1059     compile, and then install this package. </p>
1060
1061
1062     <h3>Conclusion</h3>
1063
1064     <p>As you can see, adding a software to buildroot is simply a
1065     matter of writing a <i>Makefile</i> using an already existing
1066     example and to modify it according to the compilation process of
1067     the software. </p>
1068
1069     <p>If you package software that might be useful for other persons,
1070     don't forget to send a patch to Buildroot developers !</p>
1071
1072      <h2><a name="links" id="links"></a>Resources</h2>
1073
1074     <p>To learn more about Buildroot you can visit these
1075     websites:</p>
1076
1077     <ul>
1078       <li><a href="http://www.uclibc.org/">http://www.uclibc.org/</a></li>
1079       <li><a href="http://www.busybox.net/">http://www.busybox.net/</a></li>
1080     </ul>
1081
1082   </div>
1083 <!--
1084         <a href="http://validator.w3.org/check?uri=referer"><img
1085         border="0" height="31" width="88"
1086         src="images/valid-html401.png"
1087         alt="Valid HTML"></img></a>
1088 -->
1089
1090 </body>
1091 </html>