| 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> |
Archives