1 |
On Mon, 23 Aug 2010 16:22:35 -0400 |
2 |
Mike Frysinger <vapier@g.o> wrote: |
3 |
|
4 |
> On Monday, August 23, 2010 13:16:38 Michał Górny wrote: |
5 |
> > On Mon, 23 Aug 2010 12:39:50 -0400 Mike Frysinger wrote: |
6 |
> > > i'm not sure caching the value and using it in between runs is a |
7 |
> > > good idea. unless you also cache the thing you're caching and |
8 |
> > > compare it to make sure your cache is no longer invalid. |
9 |
> > > |
10 |
> > > i.e. export _SCONSOPTS_MAKEOPTS=${MAKEOPTS}, and then on every |
11 |
> > > escons invocation, make sure ${MAKEOPTS} hasnt changed in which |
12 |
> > > case you need to regenerate it. or just avoid the cache |
13 |
> > > altogether and leave SCONSOPTS as a hook specific to scons. |
14 |
> > |
15 |
> > Can do, though I don't see a reason why anyone would mangle |
16 |
> > MAKEOPTS in a middle of an ebuild using SCons. |
17 |
> |
18 |
> i agree, but you might as have it work properly in all cases instead |
19 |
> of flaking out randomly on ebuild authors. |
20 |
|
21 |
We're hitting another corner case then. What if user modifies SCONSOPTS |
22 |
in the middle of an ebuild? We could export another variable keeping |
23 |
resulting SCONSOPTS and comparing it with the current SCONSOPTS -- but |
24 |
what if the ebuild author randomly hit the same flags that resulted |
25 |
from MAKEOPTS->SCONSOPTS conversion (and changed MAKEOPTS at the same |
26 |
time)? |
27 |
|
28 |
If we consider it like that, we end up with the idea that re-generating |
29 |
SCONSOPTS every time escons() is called is the only feasible solution |
30 |
-- but I don't really think it is worth to waste the time considering |
31 |
it. |
32 |
|
33 |
-- |
34 |
Best regards, |
35 |
Michał Górny |
36 |
|
37 |
<http://mgorny.alt.pl> |
38 |
<xmpp:mgorny@××××××.ru> |