[ccache] Why not cache link commands?
vapier at gentoo.org
Tue Sep 18 15:59:25 MDT 2012
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the ccache