[Buildroot] ccache problem with codesourcery toolchain

D M d_mo1234 at yahoo.com
Thu Feb 9 02:39:16 UTC 2012


I like Arnout's "touch -r" idea.  Please find a patch attached to
this email.  It did the trick for me.

Dan -




----- Original Message -----
From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
To: D M <d_mo1234 at yahoo.com>
Cc: "buildroot at busybox.net" <buildroot at busybox.net>
Sent: Sunday, February 5, 2012 2:45 AM
Subject: Re: [Buildroot] ccache problem with codesourcery toolchain

Hello Danomi,

Le Sat, 4 Feb 2012 17:05:01 -0800 (PST),
D M <d_mo1234 at yahoo.com> a écrit :

> I am working on a project based on the 2011.08 release of buildroot.
>  We found that the ccache savings was not as good as with our older
> version of buildroot (which used an older version of ccache).  For
> example, starting from an empty cache directory, our compile takes
> about half an hour.  With the newer version of ccache, we only save
> about 3 minutes; with the older version, we saved about 13 minutes.
>  We traced the problem to a feature introduced in ccache 3.0,
> the CCACHE_COMPILERCHECK option.  Quoting from ccache manual: 
> 
>    "By default, ccache includes the modification time (“mtime”) and
> size of the compiler in the hash to ensure that results retrieved
> from the cache are accurate. The CACHE_COMPILERCHECK environment
> variable can be used to select another strategy."  
> 
> The default is "mtime", but if we select "none", we get back all of
> our savings.  Again quoting from the manual:  
> 
>     "none - Don’t hash anything. This may be good for situations
> where you can safely use the cached results even though the
> compiler’s mtime or size has changed (e.g. if the compiler is built
> as part of your build system and the compiler’s source has not
> changed, or if the compiler only has changes that don’t affect code
> generation)."
> 
> Since we are using buildroot's capability to automatically download
> and extract the CodeSourcery ARM toolchain, the "mtime" used in the
> hash is different every time we do a full recompile.  So a value of
> "none" seems appropriate when use buildroot this way.
> 
> Have others ran into this?  Since buildroot has this kind of
> CodeSourcery toolchain support, I was wondering if there should be an
> option in menuconfig to specify CCACHE_COMPILERCHECK, to, for
> example, prepend a "CCACHE_COMPILERCHECK=none" to the beginning of
> the CCACHE variable that is used to make TARGET_CC, TARGET_CXX,
> HOSTCC, HOSTCXX.

Good research! Obviously, using the default value of
CCACHE_COMPILERCHECK=mtime will completely defeat the compiler cache in
the context of Buildroot, because the compiler gets re-created pretty
much at every build, so definitely we should arrange for
CCACHE_COMPILERCHECK=none to be set in the ccache environment, or even
directly modify the ccache code to make it the default.

The thing I am curious about is where do the 3 minutes time reduction
come from even when CCACHE_COMPILERCHECK=mtime? Maybe it's the time
reduction gained on compiling host packages, since those always use the
same host compiler.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ext-toolchain-set-wrapper-date-for-ccache-mtime.patch
Type: application/octet-stream
Size: 1253 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120208/42e9d2cb/attachment-0001.obj>


More information about the buildroot mailing list