[Scons-users] StaticLibrary builder

[Kenny, Jason L]

I think we are in general agreement, 

I am not suggesting that a command line be the only way, just one way. The delayed creation of default environment I believe is a great idea, I do some stuff in Part to do this with the default ( as I allow the user to change what the default is)

I think the idea for me is that while a user can always create a command line options themselves. The ability for a system to define some common ones is useful as it reduces learning curves when using different projects using the same system.

I have a mirror to the scons-site called parts-site. I know this has been useful for tweaking and testing, but in the product logic product teams prefer a one file solution. Being able to set policy via a clean API in the SConstruct seems to be what is preferred, the as a final answer. There is even the push ( which I plan to add support for) to allow a "part" or component to define customization such as builders, or variable definition for the whole system. Given the a Part is a versionable item, this allows control over what version is added and is being used, for easy rollback and management in a number of different promotion models.
 

Jason

-----Original Message-----
From: scons-users-bounces at scons.org [mailto:scons-users-bounces at scons.org] On Behalf Of Gary Oberbrunner
Sent: Wednesday, August 08, 2012 10:52 AM
To: SCons users mailing list
Subject: Re: [Scons-users] StaticLibrary builder

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
_______________________________________________
Scons-users mailing list
Scons-users at scons.org
http://four.pairlist.net/mailman/listinfo/scons-users