e78cc3af51
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
204 lines
6.8 KiB
Plaintext
204 lines
6.8 KiB
Plaintext
// -*- mode:doc; -*-
|
|
// vim: set syntax=asciidoc:
|
|
|
|
Daily use
|
|
---------
|
|
|
|
include::rebuilding-packages.txt[]
|
|
|
|
Offline builds
|
|
~~~~~~~~~~~~~~
|
|
|
|
If you intend to do an offline build and just want to download
|
|
all sources that you previously selected in the configurator
|
|
('menuconfig', 'nconfig', 'xconfig' or 'gconfig'), then issue:
|
|
|
|
--------------------
|
|
$ make source
|
|
--------------------
|
|
|
|
You can now disconnect or copy the content of your +dl+
|
|
directory to the build-host.
|
|
|
|
Building out-of-tree
|
|
~~~~~~~~~~~~~~~~~~~~
|
|
|
|
As default, everything built by Buildroot is stored in the directory
|
|
+output+ in the Buildroot tree.
|
|
|
|
Buildroot also supports building out of tree with a syntax similar to
|
|
the Linux kernel. To use it, add +O=<directory>+ to the make command
|
|
line:
|
|
|
|
--------------------
|
|
$ make O=/tmp/build
|
|
--------------------
|
|
|
|
Or:
|
|
|
|
--------------------
|
|
$ cd /tmp/build; make O=$PWD -C path/to/buildroot
|
|
--------------------
|
|
|
|
All the output files will be located under +/tmp/build+. If the +O+
|
|
path does not exist, Buildroot will create it.
|
|
|
|
*Note:* the +O+ path can be either an absolute or a relative path, but if it's
|
|
passed as a relative path, it is important to note that it is interpreted
|
|
relative to the main Buildroot source directory, *not* the current working
|
|
directory.
|
|
|
|
When using out-of-tree builds, the Buildroot +.config+ and temporary
|
|
files are also stored in the output directory. This means that you can
|
|
safely run multiple builds in parallel using the same source tree as
|
|
long as they use unique output directories.
|
|
|
|
For ease of use, Buildroot generates a Makefile wrapper in the output
|
|
directory - so after the first run, you no longer need to pass +O=<...>+
|
|
and +-C <...>+, simply run (in the output directory):
|
|
|
|
--------------------
|
|
$ make <target>
|
|
--------------------
|
|
|
|
[[env-vars]]
|
|
|
|
Environment variables
|
|
~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Buildroot also honors some environment variables, when they are passed
|
|
to +make+ or set in the environment:
|
|
|
|
* +HOSTCXX+, the host C++ compiler to use
|
|
* +HOSTCC+, the host C compiler to use
|
|
* +UCLIBC_CONFIG_FILE=<path/to/.config>+, path to
|
|
the uClibc configuration file, used to compile uClibc, if an
|
|
internal toolchain is being built.
|
|
+
|
|
Note that the uClibc configuration file can also be set from the
|
|
configuration interface, so through the Buildroot +.config+ file; this
|
|
is the recommended way of setting it.
|
|
+
|
|
* +BUSYBOX_CONFIG_FILE=<path/to/.config>+, path to
|
|
the Busybox configuration file.
|
|
+
|
|
Note that the Busybox configuration file can also be set from the
|
|
configuration interface, so through the Buildroot +.config+ file; this
|
|
is the recommended way of setting it.
|
|
+
|
|
* +BR2_DL_DIR+ to override the directory in which
|
|
Buildroot stores/retrieves downloaded files
|
|
+
|
|
Note that the Buildroot download directory can also be set from the
|
|
configuration interface, so through the Buildroot +.config+ file; this
|
|
is the recommended way of setting it.
|
|
* +GRAPH_ALT+, if set and non-empty, to use an alternate color-scheme in
|
|
build-time graphs
|
|
* +GRAPH_OUT+ to set the filetype of generated graphs, either +pdf+ (the
|
|
default), or +png+.
|
|
|
|
An example that uses config files located in the toplevel directory and
|
|
in your $HOME:
|
|
|
|
--------------------
|
|
$ make UCLIBC_CONFIG_FILE=uClibc.config BUSYBOX_CONFIG_FILE=$HOME/bb.config
|
|
--------------------
|
|
|
|
If you want to use a compiler other than the default +gcc+
|
|
or +g+++ for building helper-binaries on your host, then do
|
|
|
|
--------------------
|
|
$ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD
|
|
--------------------
|
|
|
|
Dealing efficiently with filesystem images
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Filesystem images can get pretty big, depending on the filesystem you choose,
|
|
the number of packages, whether you provisioned free space... Yet, some
|
|
locations in the filesystems images may just be _empty_ (eg. a long run of
|
|
'zeroes'); such a file is called a _sparse_ file.
|
|
|
|
Most tools can handle sparse files efficiently, and will only store or write
|
|
those parts of a sparse file that are not empty.
|
|
|
|
For example:
|
|
|
|
* +tar+ accepts the +-S+ option to tell it to only store non-zero blocks
|
|
of sparse files:
|
|
** +tar cf archive.tar -S [files...]+ will efficiently store sparse files
|
|
in a tarball
|
|
** +tar xf archive.tar -S+ will efficiently store sparse files extracted
|
|
from a tarball
|
|
|
|
* +cp+ accepts the +--sparse=WHEN+ option (+WHEN+ is one of +auto+,
|
|
+never+ or +always+):
|
|
** +cp --sparse=always source.file dest.file+ will make +dest.file+ a
|
|
sparse file if +source.file+ has long runs of zeroes
|
|
|
|
Other tools may have similar options. Please consult their respective man
|
|
pages.
|
|
|
|
You can use sparse files if you need to store the filesystem images (eg.
|
|
to transfer from one machine to another), of if you need to send them (eg.
|
|
to the Q&A team).
|
|
|
|
Note however that flashing a filesystem image to a device while using the
|
|
sparse mode of +dd+ may result in a broken filesystem (eg. the block bitmap
|
|
of an ext2 filesystem may be corrupted; or, if you have sparse files in
|
|
your filesystem, those parts may not be all-zeroes when read back). You
|
|
should only use sparse files when handling files on the build machine, not
|
|
when transferring them to an actual device that will be used on the target.
|
|
|
|
Graphing the dependencies between packages
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
[[graph-depends]]
|
|
|
|
One of Buildroot's jobs is to know the dependencies between packages,
|
|
and make sure they are built in the right order. These dependencies
|
|
can sometimes be quite complicated, and for a given system, it is
|
|
often not easy to understand why such or such package was brought into
|
|
the build by Buildroot.
|
|
|
|
In order to help understanding the dependencies, and therefore better
|
|
understand what is the role of the different components in your
|
|
embedded Linux system, Buildroot is capable of generating dependency
|
|
graphs.
|
|
|
|
To generate a dependency graph of the full system you have compiled,
|
|
simply run:
|
|
|
|
------------------------
|
|
make graph-depends
|
|
------------------------
|
|
|
|
You will find the generated graph in
|
|
+output/graphs/graph-depends.pdf+.
|
|
|
|
If your system is quite large, the dependency graph may be too complex
|
|
and difficult to read. It is therefore possible to generate the
|
|
dependency graph just for a given package:
|
|
|
|
------------------------
|
|
make <pkg>-graph-depends
|
|
------------------------
|
|
|
|
You will find the generated graph in
|
|
+output/graph/<pkg>-graph-depends.pdf+.
|
|
|
|
Note that the dependency graphs are generated using the +dot+ tool
|
|
from the _Graphviz_ project, which you must have installed on your
|
|
system to use this feature. In most distributions, it is available as
|
|
the +graphviz+ package.
|
|
|
|
By default, the dependency graphs are generated in the PDF
|
|
format. However, by passing the +GRAPH_OUT+ environment variable, you
|
|
can switch to other output formats, such as PNG, PostScript or
|
|
SVG. All formats supported by the +-T+ option of the +dot+ tool are
|
|
supported.
|
|
|
|
--------------------------------
|
|
GRAPH_OUT=svg make graph-depends
|
|
--------------------------------
|