Re: [PATCH 0/2] bitbake.conf: gracefully work with ccache environment variables

[Jason Wessel <jason.wessel@windriver.com>]

On 05/14/2012 12:18 PM, Marko Lindqvist wrote:
> On 14 May 2012 19:09, Jason Wessel <jason.wessel@windriver.com> wrote:
>> The end user of oe-core should be free to turn off ccache, or use an
>> external ccache without impacting the sstate sums.
> 
>  ...
> 
>  External cache makes sense for anything being built by system
> compiler. Caching results of anything produced by OE-built compilers
> to user's normal cache is problematic. Rebuild of the compiler itself
> will invalidate any such cached files, but caching them in first place
> may push more valid results out from the cache. 

This is only an issue if the compiler has changed.  In my case it is
not changing, or at least it should be the same each time.  I use one
external ccache for all the embedded target work on a per build server
basis and have done so for years for non-bitbake environments.  I
would like the same functionality from bitbake based builds.

Right now with the external ccache my kernel compiles alone go from >
6 min down to < 30 seconds, so there is a definite desire on my side
to have this work.


> So you are proposing that user has to opt-out from that behavior (by
> unsetting his normal CCACHE_DIR before running bitbake) and no
> longer opt-in (by adding CCACHE_DIR to whitelist)

The defaults remain the defaults, I am not changing anything to that
end.  I only aim to have configurability via the local.conf for
various use cases surrounding ccache.  As I mentioned before I'll just
submit a new patch to add CCACHE_DIR to the hash whitelist so it is
not in the ssatate sum.  All the other problems were a result of pilot
error.

Cheers,
Jason.