2013-02-13 13:59:02 +01:00
|
|
|
// -*- mode:doc; -*-
|
|
|
|
|
// vim: set syntax=asciidoc:
|
2012-11-11 04:14:42 +01:00
|
|
|
|
|
|
|
|
[[ccache]]
|
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 +ccache+ in Buildroot
|
2011-10-10 10:46:39 +02:00
|
|
|
|
|
|
|
|
http://ccache.samba.org[ccache] is a compiler cache. It stores the
|
|
|
|
|
object files resulting from each compilation process, and is able to
|
|
|
|
|
skip future compilation of the same source file (with same compiler
|
|
|
|
|
and same arguments) by using the pre-existing object files. When doing
|
|
|
|
|
almost identical builds from scratch a number of times, it can nicely
|
|
|
|
|
speed up the build process.
|
|
|
|
|
|
|
|
|
|
+ccache+ support is integrated in Buildroot. You just have to enable
|
|
|
|
|
+Enable compiler cache+ in +Build options+. This will automatically
|
|
|
|
|
build +ccache+ and use it for every host and target compilation.
|
|
|
|
|
|
|
|
|
|
The cache is located in +$HOME/.buildroot-ccache+. It is stored
|
|
|
|
|
outside of Buildroot output directory so that it can be shared by
|
|
|
|
|
separate Buildroot builds. If you want to get rid of the cache, simply
|
|
|
|
|
remove this directory.
|
|
|
|
|
|
|
|
|
|
You can get statistics on the cache (its size, number of hits,
|
|
|
|
|
misses, etc.) by running +make ccache-stats+.
|
2013-10-10 19:50:57 +02:00
|
|
|
|
|
|
|
|
The make target +ccache-options+ and the +CCACHE_OPTIONS+ variable
|
|
|
|
|
provide more generic access to the ccache. For example
|
|
|
|
|
|
|
|
|
|
-----------------
|
|
|
|
|
# set cache limit size
|
|
|
|
|
make CCACHE_OPTIONS="--max-size=5G" ccache-options
|
|
|
|
|
|
|
|
|
|
# zero statistics counters
|
|
|
|
|
make CCACHE_OPTIONS="--zero-stats" ccache-options
|
|
|
|
|
-----------------
|
2015-10-04 17:25:32 +02:00
|
|
|
|
|
|
|
|
+ccache+ makes a hash of the source files and of the compiler options.
|
|
|
|
|
If a compiler option is different, the cached object file will not be
|
|
|
|
|
used. Many compiler options, however, contain an absolute path to the
|
|
|
|
|
staging directory. Because of this, building in a different output
|
|
|
|
|
directory would lead to many cache misses.
|
|
|
|
|
|
|
|
|
|
To avoid this issue, buildroot has the +Use relative paths+ option
|
|
|
|
|
(+BR2_CCACHE_USE_BASEDIR+). This will rewrite all absolute paths that
|
|
|
|
|
point inside the output directory into relative paths. Thus, changing
|
|
|
|
|
the output directory no longer leads to cache misses.
|
|
|
|
|
|
|
|
|
|
A disadvantage of the relative paths is that they also end up to be
|
|
|
|
|
relative paths in the object file. Therefore, for example, the debugger
|
|
|
|
|
will no longer find the file, unless you cd to the output directory
|
|
|
|
|
first.
|
|
|
|
|
|
|
|
|
|
See https://ccache.samba.org/manual.html#_compiling_in_different_directories[the
|
|
|
|
|
ccache manual's section on "Compiling in different directories"] for
|
|
|
|
|
more details about this rewriting of absolute paths.
|
