[Scons-dev] env.Clone() vs an overide environment

[Kenny, Jason L]

Hi guys,

I have been looking at the memory monster that SCons can be inside my view of the Parts addon.

On object that I get a lot of in Parts is SCons.Environment.Base objects. Parts of this is that I make a clone based every Parts, to prevent a huge host of problems that come from sharing environments in different "components". It seems to me that maybe whole way we look at Clone() is wrong. Instead of making a clean copy of all the possible mutable values, it seems that maybe it would better to use an OverrideEnvironment object. This would save a lot of memory. I need to clarify this would have to be a slightly more conservative object than the current OverrideEnvironment object in SCons in that the main issue with using it in the current form is the code:

if "/md" in env['CPPFLAGS']:
    env['CPPFLAGS'].remove(/'md')

The reason for this is that copy one write logic would not see the remove() function being called, effecting other components that would want the '/md' flags to exists.

To correct this one could make Scons overrides to the python object that could notify environment that it was modify, so it make a copy of the given object before the modification would happen. I see this is ideal, but probably technical problematic for many different reasons.

The more realistic option I think might be to just have __getitem__ function make a copy in the overrides if the user called it ( can probably do this with a state var, that says we are in Scons/internal code such as subst(), vs reading a build files). Given that most of the values are not touched by the user, only a minimum of values need to copy, ideally a lot less that we do with a normal Clone().

Any thoughts on this? I was thinking of testing this idea in Parts. It seems that this code would be a pretty simple object that would just copy paste straight into Scons if I got it working.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20130212/ceb89971/attachment.htm>