[ccache] basename of source file in hashed name in ccache

[Frank Klotz]

  On 11/08/2011 01:49 PM, Joel Rosdahl wrote:
> On 5 November 2011 01:26, Frank Klotz<frank.klotz at alcatel-lucent.com>  wrote:
>> [...] I remember quite clearly (and I just confirmed with a colleague who is
>> still there) that the file names in the cache contained BOTH the hash AND the
>> basename of the object file.
> As far as I know, the object files have always been stored using only the hash.
> However, temporary files (stored in $CCACHE_DIR in ccache<=2.4 and
> $CCACHE_DIR/tmp in ccache>=3.0) include (a prefix of) the basename.
>
>> [...] (and another string that the ccache code refers to as "size", although
>> I can't quite figure out what it's the size OF)
> It's the size of the hashed text, i.e. output from the preprocessor. This is
> just a way of making filename collisions somewhat less likely.
>
>> One place we found the basenames invaluable was tracking down a corrupted
>> object file in the cache. Once we confirmed that we had a corrupt object file
>> foo.o, we simple searched for all "*foo.o" files in the cache, compared those
>> in size and content to an actual corrupted object file in the user directory,
>> and easily removed the corrupted file from the cache. Much harder (not
>> impossible, but harder) to do this without the basenames.
> An easy way to do that is:
>
> 1. Remove foo.o from the build tree.
> 2. Build with CCACHE_LOGFILE set to a log file.
> 3. Look for "Created foo.o from X" (where X is a file in the cache) in the log
>     file.
> 4. Remove X.
>
> Or even easier:
>

Suggestion:  Put the below 2-line solution in the "Corrupt object files" 
section of
http://ccache.samba.org/manual.html

> 1. Remove foo.o from the build tree.
> 2. Build with CCACHE_RECACHE set.

It's a LOT lighter-weight solution than clearing the cache, and much 
easier than messing with the log.

Thanks,
Frank

>> [...] Anyway, is there a general consensus on whether this would be valuable?
> It doesn't sound like a good idea to me, at least, since you would need to
> store duplicate copies of the object file for two compilations where the source
> content is the same but the file names differ.
>
> -- Joel