[ccache] Why not cache link commands?

[Justin Lebar]

> What I'm looking for is more concrete
> roadblocks I haven't considered.

You'd basically have to rewrite all of ccache.

ccache hashes header files and spits out object files.

ldcache would hash object files and spit out linked files.  It would
use an entirely separate cache.  Its handling of command-line options
would be entirely different.  Its processing of input files would be
entirely different.  ISTM that very little would be shared.

Since this is targeting a niche use-case and is a large change to
ccache, I'd be hesitant to take this change upstream, if I were Joel.

-Justin

On Tue, Sep 18, 2012 at 11:27 AM, Andrew Stubbs <ams at codesourcery.com> wrote:
> On 18/09/12 15:31, Justin Lebar wrote:
>>>
>>> So, again, before I waste my time implementing this feature, are there
>>> any
>>> other fundamental gotchas that would prevent it ever working or ever
>>> being
>>> useful?
>>
>>
>> On a large project with many inputs to ld, you'd have to hash a /lot/
>> of object files, increasing the overhead of ccache substantially.  I
>> understand that this isn't your particular use-case, but it's the
>> common one.
>
>
> Yes, that's true, but those are also the most expensive link commands, so
> maybe it's not so bad.
>
> I realise that there's some risk that a cache miss can be expensive, and
> that a cache hit might be only a very little cheaper than the real link, but
> I'm prepared to take that risk. What I'm looking for is more concrete
> roadblocks I haven't considered.
>
> Incidentally, I'm also considering the possibility of caching the hashes and
> using the inode/size/mtime etc. to short-cut that process (perhaps as a
> "sloppiness" option), not only for objects, but also for sources.
>
>
>> If you're on Linux, have you tried the gold linker?
>
>
> Let's limit this discussion to what can be done with ccache, please. I
> assure you, we know about the toolchain options.
>
> Andrew