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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ ccache mailing list [email protected] https://lists.samba.org/mailman/listinfo/ccache
