1 |
On Mon, Feb 13, 2006 at 08:06:24PM -0600, R Hill wrote: |
2 |
> (sorry if this double posts) |
3 |
> |
4 |
> Brian Harring wrote: |
5 |
> >Yo... |
6 |
> > |
7 |
> >attached is a patch enabling confcache support for portage. Lots of |
8 |
> >testing, plus fixups from comments from folks prior. |
9 |
> > |
10 |
> >So... giving it a few days, nows the time to bitch if you dislike the |
11 |
> >implementation (and no, I'm not rewriting all of doebuild just for |
12 |
> >this :) |
13 |
> |
14 |
> Well, i've been testing this on an x86 laptop and an x86_64 box over the |
15 |
> weekend. Good news is that when it works, it works well. Bad news is I've |
16 |
> yet to be able to get through an 'emerge -e world' without at least a dozen |
17 |
> build failures that resolve themselves when i clear the cache. |
18 |
|
19 |
Specific merge list would be wonderful... ;) |
20 |
|
21 |
> The errors |
22 |
> range between unresolved symbols to 'platform does not support (null)' to |
23 |
|
24 |
Err... that one I'd be very interested in. |
25 |
|
26 |
> compiler cannot create C executables to a simple file not found |
27 |
|
28 |
> and everything in between. they sometimes crop up during configure, sometimes |
29 |
> during compile, and sometimes during install. |
30 |
|
31 |
What version of sandbox are you running? You seem to be having a |
32 |
helluva lot more problems then I do; further, 'file not found' |
33 |
(depending on the m4 leading up to it) is indicative that tracking of |
34 |
file access is failing on your machine (iow, if validiation isn't |
35 |
working properly, I'm not surprised you're hitting holy hell). |
36 |
|
37 |
So... what features you got, and what sandbox version? |
38 |
|
39 |
|
40 |
> This seems to me like it would be a nightmare for maintainers. |
41 |
|
42 |
Potentialy, hence a buttload of work put in attempting to verify that |
43 |
confcache's validation checks are air tight. Flat out contrary/broken |
44 |
cache snippets in a configure script (python's dlopen check) cannot be |
45 |
dealt with beyond restricting that package, and/or correcting the |
46 |
configure statement so it's inline with what is globally the norm. |
47 |
|
48 |
Personally, I will state this- same for ccache[1], I wouldn't use |
49 |
confcache on production hardware at this stage. |
50 |
|
51 |
|
52 |
[1] ccache hands off to whatever ${CCACHE_CC-${0}} it finds next in |
53 |
traversing $PATH; if whatever that is, does further expansion/mangling |
54 |
of args to gcc (insane, but does occur) it's outside of ccache's |
55 |
knowledge of the inputs, thus validation can be horked. |
56 |
|
57 |
> There are apparently a lot of broken configures out there. |
58 |
|
59 |
Not as many as you would think actually; just takes one to cause some |
60 |
issues though. My personal experience has been different from yours, |
61 |
but reports re: confcache I've been watching/weary about. |
62 |
|
63 |
One potential alternative is breaking the cache down so it's per cp |
64 |
instead of global; doing that is easy enough, but potentially |
65 |
nukes the gain since each cache is only used on re-emerge/updates to a |
66 |
cp. |
67 |
|
68 |
|
69 |
Personally, any bug reports that come in with confcache enabled should |
70 |
have the confcache disabled imo; just the same as potentially whonky |
71 |
cflags, scale it back to ensure the problem is in the source, not in |
72 |
any bastardization's the users configuration has done to it. |
73 |
|
74 |
Meanwhile, if you're getting failures up the ying yang and it's not |
75 |
tracked down, I'd state tabling the feature (or tagging massively |
76 |
hideous warnings regarding it) is required. Iirc, solar ran a |
77 |
full build with confcache enabled (believe it was 0.3.*), so input |
78 |
from him would be useful also for comparison. |
79 |
|
80 |
Sidenote, confcache isn't prelink aware. Anyone running prelink will |
81 |
suffer continual invalidation everytime they run prelink -afmr... |
82 |
probably should do something about that. :) |
83 |
|
84 |
~harring |