[ccache] Why not cache link commands?

[Mike Frysinger]

On Tuesday 18 September 2012 17:07:53 Andrew Stubbs wrote:
> On 18/09/12 21:04, Mike Frysinger wrote:
> > On Tuesday 18 September 2012 08:44:29 Andrew Stubbs wrote:
> >> Clearly there are some technical challenges in doing this: we'd have to
> >> hash all the object files and libraries (a la direct mode), but those
> >> problems are surmountable, I think.
> > 
> > or just re-use build-id ...
> 
> Sorry, I'm probably being thick, but what do you mean?

the linker's --build-id and associated .note.gnu.build-id section.  you can't 
hash the entire object because it can change between compiles.  build-id lets 
you say "regardless of the hash of the entire object, we know the content that 
matters is unchanged".

> >> The linker does not use any libraries not listed with "gcc '-###'
> >> whatever".
> > 
> > mmm different gcc flags can implicitly expand into -l### or different crt
> > objects, so you can't cache linking at the compiler driver level w/out
> > re- implementing much of the guts of gcc, and even then you'd break with
> > moderately patched gcc versions.
> 
> "-###" isn't meant to be a wildcard. That's an actual GCC option. I put
> quotes around it because most shells would interpret the hashes as the
> start of a comment.

hmm, gotcha.  it does seem to include all the necessary info.  whether it's 
easy for a machine to parse across gcc versions is a diff question :).  seems 
to have changed subtly over time between 3.3.6 and 4.7.1.

> >> I'm also aware that it's not that interesting for many incremental
> >> builds, where the final link will always be different, but my use case
> >> is accelerating rebuilds of projects that my have many outputs, most of
> >> which are likely to be unaffected by small code changes. It's also worth
> >> noting that incremental builds are not the target use case for ccache in
> >> general.
> > 
> > gold should already support incremental linking (ala build-id), so i
> > don't think that's already a fixed problem

err, typo here.  s/don't//.

> As I said, the interesting use case is *not* incremental links. The
> interesting use case is accelerating "clean" builds. ccache can never
> help where genuinely new inputs are involved.

right, i was just agreeing with you and providing more details as to how it 
already works today.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.samba.org/pipermail/ccache/attachments/20120918/8ee5cb10/attachment.pgp>