Brandon Mintern ha scritto:
I had thought the same thing myself some time ago, and I discovered that there had been work on a FEATURE called confcache. I believe it was abandoned, though, due to major difficulties. This is merely a guess, but I think some of the problems arise in that some of the things that are checked for actually change as a package is installed or updated (e.g. checking gcc version). This means that each package being installed would have to somehow flag confcache and indicate that it has changed, and confcache would have to keep a list of all these cached values and their dependencies.
What was the problem with that? Ebuilds of stuff like gcc could be tailored to flag confcache. Otherwise, emerge could do the relevant checks before emerging the first package, and be trained to do them again after a known "troublesome" package has been emerged.
I understand this requires coordination and maintaining, of course, and that's the non-trivial part, I guess. However, are there many packages affecting common configure checks? If they are, say, less than 10 affecting 80% of configure flags, it seems worth the hassle. If troubles arise, one can quickly try with confcache disabled, and debug.
Heck, I'd help with it myself, if only I had some confidence with portage code and C compilation (However, I know Python, FWIW)
m. -- [email protected] mailing list
