2012-11-11 04:14:42 +01:00
|
|
|
// -*- mode:doc; -*-
|
2013-02-13 13:59:02 +01:00
|
|
|
// vim: set syntax=asciidoc:
|
2012-11-11 04:14:42 +01:00
|
|
|
|
manual: high-level restructuring
The structure of the buildroot manual is not always clear. There is a large
number of chapters, and some chapters seem to overlap. The distinction
between general usage and developer information is not always clear.
This patch restructures the manual into four large parts:
- getting started
- user guide
- developer guide
- appendix
Except for the names of these parts, the section names are not yet changed.
Content-wise there are no changes yet either. This will be handled in
subsequent patches.
In order to achieve the introduction of a new level 'parts' above
'chapters', the section indicators (=, ==, ===, ...) of several sections
have to be moved one level down. Additionally, the leveloffset indication to
asciidoc has to be removed. Finally, to maintain more or less the same level
of detail in the table of contents, the toc.section.depth attribute is
reduced as well. Note that for some sections, less detail is visible now.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-12 22:20:06 +02:00
|
|
|
==== Using the generated toolchain outside Buildroot
|
2011-10-10 10:46:39 +02:00
|
|
|
|
|
|
|
|
You may want to compile, for your target, 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 is located by default in
|
|
|
|
|
+output/host/+. The simplest way to use it is to add
|
2017-07-05 13:14:32 +02:00
|
|
|
+output/host/bin/+ to your PATH environment variable and then to
|
2011-10-10 10:46:39 +02:00
|
|
|
use +ARCH-linux-gcc+, +ARCH-linux-objdump+, +ARCH-linux-ld+, etc.
|
|
|
|
|
|
core/sdk: generate the SDK tarball ourselves
Currently, the wording in the manual instructs the user to generate a
tarball from "the contents of the +output/host+ directory".
This is pretty confusing, because taken literally, this would amount to
running a command like:
tar cf my-sdk.tar -C output/host/ .
This creates a tarbomb [0], which is very bad practice, because when
extracted, it creates multiple files in the current directory.
What one really wants to do, is create a tarball of the host/ directory,
with something like:
tar cf my-sdk.tar -C output host/
However, this is not much better, because the top-most directory would
have a very common name, host/, which is pretty easy to get conflict
with when it gets extracted.
So, we fix that mess by giving the top-most directory a recognisable
name, based on the target tuple, which we also use as the name of the
archive (suffixed with the usual +.tar.gz+.) We offer the user the
possibility to override that default by specifying the +BR2_SDK_PREFIX+
variable on the command line.
Since this is an output file, we place it in the images/ directory.
As some users expressed a very strong feeling that they do not want to
generate a tarball at all, and that doing so would badly hurt their
workflows [1], we actually prepare the SDK as was previously done, but
under the new, intermediate rule 'prepare-sdk'. The existing 'sdk' rule
obviously depend on that before generating the tarball.
We choose to make the existing rule to generate the tarball, and
introduce a new rule to just prepare the SDK, rather than keep the
existing rule as-is and introduce a new one to generate the tarball,
because it makes sense to have the simplest rule do the correct thing,
leaving advanced, power users use the longest command. If someone
already had a wrapper that called 'sdk' and expected just the host
directory to be prepared, then this is not broken; it just takes a bit
longer (gzip is pretty fast).
Update the manual accordingly.
[0] https://en.wikipedia.org/wiki/Tar_(computing)#Tarbomb
[1] http://lists.busybox.net/pipermail/buildroot/2018-June/thread.html#223377
and some messages in the ensuing thread...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Stefan Becker <chemobejk@gmail.com>
Cc: Trent Piepho <tpiepho@impinj.com>
Signed-off-by: "Yann E. MORIN" <<a href="mailto:yann.morin.1998@free.fr" target="_blank">yann.morin.1998@free.fr</a>><br>
Reviewed-by: Stefan Becker <chemobejk@gmail.com>
Signed-off-by: "Yann E. MORIN" <<a href="mailto:yann.morin.1998@free.fr" target="_blank">yann.morin.1998@free.fr</a>><br>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-08-04 10:27:41 +02:00
|
|
|
Alternatively, Buildroot can also export the toolchain and the development
|
|
|
|
|
files of all selected packages, as an SDK, by running the command
|
|
|
|
|
+make sdk+. This generates a tarball of the content of the host directory
|
|
|
|
|
+output/host/+, named +<TARGET-TUPLE>_sdk-buildroot.tar.gz+ (which can be
|
|
|
|
|
overriden by setting the environment variable +BR2_SDK_PREFIX+) and
|
|
|
|
|
located in the output directory +output/images/+.
|
2018-02-18 15:50:42 +01:00
|
|
|
|
core/sdk: generate the SDK tarball ourselves
Currently, the wording in the manual instructs the user to generate a
tarball from "the contents of the +output/host+ directory".
This is pretty confusing, because taken literally, this would amount to
running a command like:
tar cf my-sdk.tar -C output/host/ .
This creates a tarbomb [0], which is very bad practice, because when
extracted, it creates multiple files in the current directory.
What one really wants to do, is create a tarball of the host/ directory,
with something like:
tar cf my-sdk.tar -C output host/
However, this is not much better, because the top-most directory would
have a very common name, host/, which is pretty easy to get conflict
with when it gets extracted.
So, we fix that mess by giving the top-most directory a recognisable
name, based on the target tuple, which we also use as the name of the
archive (suffixed with the usual +.tar.gz+.) We offer the user the
possibility to override that default by specifying the +BR2_SDK_PREFIX+
variable on the command line.
Since this is an output file, we place it in the images/ directory.
As some users expressed a very strong feeling that they do not want to
generate a tarball at all, and that doing so would badly hurt their
workflows [1], we actually prepare the SDK as was previously done, but
under the new, intermediate rule 'prepare-sdk'. The existing 'sdk' rule
obviously depend on that before generating the tarball.
We choose to make the existing rule to generate the tarball, and
introduce a new rule to just prepare the SDK, rather than keep the
existing rule as-is and introduce a new one to generate the tarball,
because it makes sense to have the simplest rule do the correct thing,
leaving advanced, power users use the longest command. If someone
already had a wrapper that called 'sdk' and expected just the host
directory to be prepared, then this is not broken; it just takes a bit
longer (gzip is pretty fast).
Update the manual accordingly.
[0] https://en.wikipedia.org/wiki/Tar_(computing)#Tarbomb
[1] http://lists.busybox.net/pipermail/buildroot/2018-June/thread.html#223377
and some messages in the ensuing thread...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Stefan Becker <chemobejk@gmail.com>
Cc: Trent Piepho <tpiepho@impinj.com>
Signed-off-by: "Yann E. MORIN" <<a href="mailto:yann.morin.1998@free.fr" target="_blank">yann.morin.1998@free.fr</a>><br>
Reviewed-by: Stefan Becker <chemobejk@gmail.com>
Signed-off-by: "Yann E. MORIN" <<a href="mailto:yann.morin.1998@free.fr" target="_blank">yann.morin.1998@free.fr</a>><br>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-08-04 10:27:41 +02:00
|
|
|
This tarball can then be distributed to application developers, when
|
|
|
|
|
they want to develop their applications that are not (yet) packaged as
|
|
|
|
|
a Buildroot package.
|
2018-02-18 15:50:42 +01:00
|
|
|
|
core/sdk: generate the SDK tarball ourselves
Currently, the wording in the manual instructs the user to generate a
tarball from "the contents of the +output/host+ directory".
This is pretty confusing, because taken literally, this would amount to
running a command like:
tar cf my-sdk.tar -C output/host/ .
This creates a tarbomb [0], which is very bad practice, because when
extracted, it creates multiple files in the current directory.
What one really wants to do, is create a tarball of the host/ directory,
with something like:
tar cf my-sdk.tar -C output host/
However, this is not much better, because the top-most directory would
have a very common name, host/, which is pretty easy to get conflict
with when it gets extracted.
So, we fix that mess by giving the top-most directory a recognisable
name, based on the target tuple, which we also use as the name of the
archive (suffixed with the usual +.tar.gz+.) We offer the user the
possibility to override that default by specifying the +BR2_SDK_PREFIX+
variable on the command line.
Since this is an output file, we place it in the images/ directory.
As some users expressed a very strong feeling that they do not want to
generate a tarball at all, and that doing so would badly hurt their
workflows [1], we actually prepare the SDK as was previously done, but
under the new, intermediate rule 'prepare-sdk'. The existing 'sdk' rule
obviously depend on that before generating the tarball.
We choose to make the existing rule to generate the tarball, and
introduce a new rule to just prepare the SDK, rather than keep the
existing rule as-is and introduce a new one to generate the tarball,
because it makes sense to have the simplest rule do the correct thing,
leaving advanced, power users use the longest command. If someone
already had a wrapper that called 'sdk' and expected just the host
directory to be prepared, then this is not broken; it just takes a bit
longer (gzip is pretty fast).
Update the manual accordingly.
[0] https://en.wikipedia.org/wiki/Tar_(computing)#Tarbomb
[1] http://lists.busybox.net/pipermail/buildroot/2018-June/thread.html#223377
and some messages in the ensuing thread...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Stefan Becker <chemobejk@gmail.com>
Cc: Trent Piepho <tpiepho@impinj.com>
Signed-off-by: "Yann E. MORIN" <<a href="mailto:yann.morin.1998@free.fr" target="_blank">yann.morin.1998@free.fr</a>><br>
Reviewed-by: Stefan Becker <chemobejk@gmail.com>
Signed-off-by: "Yann E. MORIN" <<a href="mailto:yann.morin.1998@free.fr" target="_blank">yann.morin.1998@free.fr</a>><br>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-08-04 10:27:41 +02:00
|
|
|
Upon extracting the SDK tarball, the user must run the script
|
|
|
|
|
+relocate-sdk.sh+ (located at the top directory of the SDK), to make
|
|
|
|
|
sure all paths are updated with the new location.
|
2011-10-10 10:46:39 +02:00
|
|
|
|
core/sdk: generate the SDK tarball ourselves
Currently, the wording in the manual instructs the user to generate a
tarball from "the contents of the +output/host+ directory".
This is pretty confusing, because taken literally, this would amount to
running a command like:
tar cf my-sdk.tar -C output/host/ .
This creates a tarbomb [0], which is very bad practice, because when
extracted, it creates multiple files in the current directory.
What one really wants to do, is create a tarball of the host/ directory,
with something like:
tar cf my-sdk.tar -C output host/
However, this is not much better, because the top-most directory would
have a very common name, host/, which is pretty easy to get conflict
with when it gets extracted.
So, we fix that mess by giving the top-most directory a recognisable
name, based on the target tuple, which we also use as the name of the
archive (suffixed with the usual +.tar.gz+.) We offer the user the
possibility to override that default by specifying the +BR2_SDK_PREFIX+
variable on the command line.
Since this is an output file, we place it in the images/ directory.
As some users expressed a very strong feeling that they do not want to
generate a tarball at all, and that doing so would badly hurt their
workflows [1], we actually prepare the SDK as was previously done, but
under the new, intermediate rule 'prepare-sdk'. The existing 'sdk' rule
obviously depend on that before generating the tarball.
We choose to make the existing rule to generate the tarball, and
introduce a new rule to just prepare the SDK, rather than keep the
existing rule as-is and introduce a new one to generate the tarball,
because it makes sense to have the simplest rule do the correct thing,
leaving advanced, power users use the longest command. If someone
already had a wrapper that called 'sdk' and expected just the host
directory to be prepared, then this is not broken; it just takes a bit
longer (gzip is pretty fast).
Update the manual accordingly.
[0] https://en.wikipedia.org/wiki/Tar_(computing)#Tarbomb
[1] http://lists.busybox.net/pipermail/buildroot/2018-June/thread.html#223377
and some messages in the ensuing thread...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Stefan Becker <chemobejk@gmail.com>
Cc: Trent Piepho <tpiepho@impinj.com>
Signed-off-by: "Yann E. MORIN" <<a href="mailto:yann.morin.1998@free.fr" target="_blank">yann.morin.1998@free.fr</a>><br>
Reviewed-by: Stefan Becker <chemobejk@gmail.com>
Signed-off-by: "Yann E. MORIN" <<a href="mailto:yann.morin.1998@free.fr" target="_blank">yann.morin.1998@free.fr</a>><br>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-08-04 10:27:41 +02:00
|
|
|
Alternatively, if you just want to prepare the SDK without generating
|
|
|
|
|
the tarball (e.g. because you will just be moving the +host+ directory,
|
|
|
|
|
or will be generating the tarball on your own), Buildroot also allows
|
|
|
|
|
you to just prepare the SDK with +make prepare-sdk+ without actually
|
|
|
|
|
generating a tarball.
|
2020-10-27 15:01:40 +01:00
|
|
|
|
|
|
|
|
For your convenience, by selecting the option
|
|
|
|
|
+BR2_PACKAGE_HOST_ENVIRONMENT_SETUP+, you can get a
|
2020-12-31 22:29:47 +01:00
|
|
|
+environment-setup+ script installed in +output/host/+ and therefore
|
2020-10-27 15:01:40 +01:00
|
|
|
in your SDK. This script can be sourced with
|
|
|
|
|
+. your/sdk/path/environment-setup+ to export a number of environment
|
|
|
|
|
variables that will help cross-compile your projects using the
|
|
|
|
|
Buildroot SDK: the +PATH+ will contain the SDK binaries, standard
|
|
|
|
|
_autotools_ variables will be defined with the appropriate values, and
|
|
|
|
|
+CONFIGURE_FLAGS+ will contain basic +./configure+ options to
|
2020-04-28 16:45:59 +02:00
|
|
|
cross-compile _autotools_ projects. It also provides some useful
|
|
|
|
|
commands. Note however that once this script is sourced, the
|
|
|
|
|
environment is setup only for cross-compilation, and no longer for
|
|
|
|
|
native compilation.
|
