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

Frank Klotz frank.klotz at alcatel-lucent.com
Wed Nov 9 10:46:35 MST 2011


  On 11/08/2011 11:08 PM, Joel Rosdahl wrote:
> On 8 November 2011 23:18, Frank Klotz<frank.klotz at alcatel-lucent.com>  wrote:
>> On 11/08/2011 01:49 PM, Joel Rosdahl wrote:
>>> 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.
>> 1: Would that EVER happen? (I am having trouble visualizing a situation where
>> this would be a good thing.)
> Don't know, but yes, it's probably quite rare.
>
>> 2: If it DID happen, rather than 2 copies, could store one inode with 2
>> directory entries (hard links) with the 2 names.
> I don't think you can in an acceptable way find an existing file to reuse when
> you're about to store a new file -- you'll have to list the directory and
> iterate through its items to look for a reusable file. (That is, unless you
> introduce some kind of higher-level index that makes it possible to efficiently
> list existing files with a given hash.)

Maybe I'm confused again, but since they have the same hash hhh, 
wouldn't it in fact be trivially EASY to find them?  The subdirectory 
selection still depends on the hash, so both files would be in the same 
directory, and when you are looking to create hhh.foo.o in that 
directory, you can first look for hhh.*.o, and when you find hhh.bar.o, 
you know you have different sources (foo and bar) that preprocess to the 
same result (represented by hhh), so you can create hhh.foo.o as a hard 
link to hhh.bar.o, rather than as a separate copy.

Academic though, as I suspect this would happen very rarely; and it only 
matters if some one DOES decide to add an option to include basenames in 
the ccache hash (since otherwise the same hash would just find the 
existing file.)

I'm willing to drop this request (including source file name in the 
cache file name) - it is probably not a significant improvement.

Thanks,
Frank
> -- Joel



More information about the ccache mailing list