[ccache] Stumbling blocks with ccache and embedded/encapsulated environments

[Joel Rosdahl]

On 2010-11-10 23:54, Paul Smith wrote:
 > [...]
> So, my question is, is the NAME of the compiler part of the hash as well
> as the mtime/size, so that ccache won't consider the second one to be a
> copy of the first?

Yes, the compiler name is included in the hash. As you note, this is not 
clear from the current documentation. I will add a clarification. Thanks!

> Of course I can always resort to CCACHE_COMPILERCHECK='%compiler% -v'
> which will tell me what I want to know (that these compilers are very
> different).  But it would be nice to avoid that overhead if possible.

Yes, if it's enough for you to rely on the compiler name, then it should 
work to use CCACHE_COMPILERCHECK=mtime if the wrapper script changes 
each time a new compiler is installed. (But that will of course 
invalidate other compilers' cached results as well.)

I added the CCACHE_COMPILERCHECK='%compiler% -v' thing exactly for the 
wrapper script scenario, so if it's fast enough I think it would be the 
best setup. If the overhead is too high, then maybe you could write a 
fast helper program that knows how to print suitable compiler version 
information on stdout and then set CCACHE_COMPILERCHECK='helper_program 
%compiler%'.

> Also if I DO go with CCACHE_COMPILERCHECK, is ONLY that output part of
> the hash?  Or is the mtime/size for the compiler also part of the hash?

mtime/size is only hashed when CCACHE_COMPILERCHECK=mtime.

> It would be nice for debugging/etc. if there was a way to see exactly
> what elements are going into the hash for a given target.

That would indeed be very useful, and it's something I plan to add when 
implementing ability to select different hash algorithms.

-- Joel