[ccache] Why not cache link commands?
ams at codesourcery.com
Tue Sep 18 15:07:53 MDT 2012
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 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.
"-###" causes gcc to print the commands that it would run, including the
link line (well, collect2, but same difference). We can read that and
bypass reimplementing all of gcc. As you say, without this feature we
couldn't predict what gcc will do: the compiler wouldn't even need to be
patched if customer specs files were used.
>> 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
> gold should already support incremental linking (ala build-id), so i don't
> think that's already a fixed problem
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.
More information about the ccache