[Scons-users] StaticLibrary builder

[Kenny, Jason L]

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.

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:22 AM
To: SCons users mailing list
Subject: Re: [Scons-users] StaticLibrary builder

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

> You can add 'default' tool to the tools, but if you are like me and 

> want to reduce what is loaded to what is needed. I define these tools 

> for the gcc toolchain ( which is something I want to get in to SCons 

> with a new Setting (IAPAT) object) in Parts,

>

> environment = Environment(tools=['gcc','g++','ar','gas','gnulink'])

>

> I think that should add what you are missing.


Just a quick note on this: presumably you're doing that to speed up startup time?  Unfortunately that doesn't work, because SCons initializes the default env before even loading the SConstruct, and it sets up all the default tools there.  That is one of the reasons, for me, of revamping the tool chain -- to avoid that.

--
Gary
_______________________________________________
Scons-users mailing list
Scons-users at scons.org
http://four.pairlist.net/mailman/listinfo/scons-users