[ccache] Stumbling blocks with ccache and embedded/encapsulated environments
joel at rosdahl.net
Thu Nov 11 14:16:25 MST 2010
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
> 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.
More information about the ccache