[Scons-users] StaticLibrary builder

[Gary Oberbrunner]

On Wed, Aug 8, 2012 at 11:33 AM, Kenny, Jason L <jason.l.kenny at intel.com> wrote:

> I agree,

>

> The value I get out of this is that I have to create a 1000 different environment ( new record I believe I just saw). Here this makes a huge difference, and the use of clone for environments that are similar.

>

> This is why I feel the proposal I have for adding a toolchain directory with some sort of data about the toolchain is a must. The proposal Greg has with IAPAT does not solve this issue, as it requires the user to define what toolchains they want in the SConstruct file. Being able to define a file that scons can be told about with a --tool-chain like switch means we have control over what is loaded and what is not. Given the support certain cross platform cases such as NDK android I have, I think this needs to go into SCons.


I agree.  I don't think a command-line arg is the right (or only)
solution though.  I think we have to allow the SConstruct to specify
what goes in the default env -- this is probably not all that hard to
do, just defer the creation of the default env til some later point,
after the SConstruct makes some setup calls -- or even do it lazily,
so if the default env is never used, it never gets created).  We could
have a site_scons solution but I'd prefer to allow this kind of
configuration to be possible in a single-SConstruct workflow.  Of
course once we have a way to programmatically set a toolchain on any
env (including default), then a user can even create a command-line
arg to do it.

I have other related ideas about mechanism vs. policy and SCons as a
construction set rather than a finished tool -- but that's for another
email.

-- 
Gary