Re: [gentoo-portage-dev] Re: confcache, final chance to ixnay it

[Brian Harring]

On Mon, Feb 13, 2006 at 08:06:24PM -0600, R Hill wrote:
> (sorry if this double posts)
>
> Brian Harring wrote:
> >Yo...
> >
> >attached is a patch enabling confcache support for portage.  Lots of
> >testing, plus fixups from comments from folks prior.
> >
> >So... giving it a few days, nows the time to bitch if you dislike the
> >implementation (and no, I'm not rewriting all of doebuild just for
> >this :)
>
> Well, i've been testing this on an x86 laptop and an x86_64 box over the
> weekend.  Good news is that when it works, it works well.  Bad news is I've
> yet to be able to get through an 'emerge -e world' without at least a dozen
> build failures that resolve themselves when i clear the cache.

Specific merge list would be wonderful... ;)

> The errors
> range between unresolved symbols to 'platform does not support (null)' to

Err... that one I'd be very interested in.  

> compiler cannot create C executables to a simple file not found

> and everything in between.  they sometimes crop up during configure, sometimes
> during compile, and sometimes during install.

What version of sandbox are you running?  You seem to be having a 
helluva lot more problems then I do; further, 'file not found' 
(depending on the m4 leading up to it) is indicative that tracking of 
file access is failing on your machine (iow, if validiation isn't 
working properly, I'm not surprised you're hitting holy hell).

So... what features you got, and what sandbox version?


> This seems to me like it would be a nightmare for maintainers.

Potentialy, hence a buttload of work put in attempting to verify that 
confcache's validation checks are air tight.  Flat out contrary/broken 
cache snippets in a configure script (python's dlopen check) cannot be 
dealt with beyond restricting that package, and/or correcting the 
configure statement so it's inline with what is globally the norm.

Personally, I will state this- same for ccache[1], I wouldn't use 
confcache on production hardware at this stage.


[1] ccache hands off to whatever ${CCACHE_CC-${0}} it finds next in 
traversing $PATH; if whatever that is, does further expansion/mangling 
of args to gcc (insane, but does occur) it's outside of ccache's 
knowledge of the inputs, thus validation can be horked.

> There are apparently a lot of broken configures out there.

Not as many as you would think actually; just takes one to cause some 
issues though.  My personal experience has been different from yours, 
but reports re: confcache I've been watching/weary about.

One potential alternative is breaking the cache down so it's per cp 
instead of global; doing that is easy enough, but potentially 
nukes the gain since each cache is only used on re-emerge/updates to a 
cp.


Personally, any bug reports that come in with confcache enabled should 
have the confcache disabled imo; just the same as potentially whonky 
cflags, scale it back to ensure the problem is in the source, not in 
any bastardization's the users configuration has done to it.

Meanwhile, if you're getting failures up the ying yang and it's not 
tracked down, I'd state tabling the feature (or tagging massively 
hideous warnings regarding it) is required.  Iirc, solar ran a 
full build with confcache enabled (believe it was 0.3.*), so input 
from him would be useful also for comparison.

Sidenote, confcache isn't prelink aware.  Anyone running prelink will 
suffer continual invalidation everytime they run prelink -afmr... 
probably should do something about that. :)

~harring