Re: [gentoo-dev] New eclass: scons.eclass

[Mike Frysinger]

On Monday, August 23, 2010 19:02:21 Michał Górny wrote:
> On Mon, 23 Aug 2010 16:22:35 -0400 Mike Frysinger wrote:
> > On Monday, August 23, 2010 13:16:38 Michał Górny wrote:
> > > On Mon, 23 Aug 2010 12:39:50 -0400 Mike Frysinger wrote:
> > > > i'm not sure caching the value and using it in between runs is a
> > > > good idea. unless you also cache the thing you're caching and
> > > > compare it to make sure your cache is no longer invalid.
> > > >
> > > > i.e. export _SCONSOPTS_MAKEOPTS=${MAKEOPTS}, and then on every
> > > > escons invocation, make sure ${MAKEOPTS} hasnt changed in which
> > > > case you need to regenerate it.  or just avoid the cache
> > > > altogether and leave SCONSOPTS as a hook specific to scons.
> > >
> > > Can do, though I don't see a reason why anyone would mangle
> > > MAKEOPTS in a middle of an ebuild using SCons.
> >
> > i agree, but you might as have it work properly in all cases instead
> > of flaking out randomly on ebuild authors.
>
> We're hitting another corner case then. What if user modifies SCONSOPTS
> in the middle of an ebuild? We could export another variable keeping
> resulting SCONSOPTS and comparing it with the current SCONSOPTS -- but
> what if the ebuild author randomly hit the same flags that resulted
> from MAKEOPTS->SCONSOPTS conversion (and changed MAKEOPTS at the same
> time)?
>
> If we consider it like that, we end up with the idea that re-generating
> SCONSOPTS every time escons() is called is the only feasible solution
> -- but I don't really think it is worth to waste the time considering
> it.

then keep it simple and separate:
escons() {
	debug-print-function ${FUNCNAME} "${@}"

	set -- scons $(scons_clean_makeopts) ${SCONSOPTS} ${EXTRA_ESCONS} "${@}"
	echo "${@}" >&2
	"${@}"
}

now you dont have to worry about changes between invocations and the developer 
has a clear path -- if they need to force a serial build for example, they can 
either append MAKEOPTS, SCONSOPTS, or pass it straight to escons.  no cache 
confusion or desync between the vars.
-mike