[Scons-users] DefaultEnvironment (was Re: StaticLibrary builder)

Gary Oberbrunner garyo at oberbrunner.com
Thu Aug 9 08:46:53 EDT 2012


On Thu, Aug 9, 2012 at 12:53 AM, Bill Deegan <bill at baddogconsulting.com> wrote:

> Greg,

>

> On Wed, Aug 8, 2012 at 7:15 PM, Greg Ward <greg at gerg.ca> wrote:

>>

>> On 08 August 2012, Bill Deegan said:

>> > As an aside, I'd like to get rid of DefaultEnvironment entirely.

>>

>> Really? My SConstruct does this

>>

>> env = DefaultEnvironment(

>> ...vars...

>> )

>>

>> and then every SConscript starts with

>>

>> env = DefaultEnvironment()

>>

>> or

>>

>> env = DefaultEnvironment().Clone()

>>

>> and it all works great. Should I be using Import() and Export() instead?

>>

>> (I really dislike Import() and export() on aesthetic grounds, because

>> they conflate names and strings. Yuck.)

>

>

> Interesting usage.

> But I don't like things that happen auto-magically.

> I like explicit.

>

> Also Import/Export don't bother me in any way.


I noticed this behavior last year (that you can modify what
DefaultEnvironment() returns, and that becomes "sticky") and
considered it a bug. It's not the default environment anymore if you
can modify it, right? (Of course the point is arguable -- you're
making it *your* default.) But I don't think it's good SCons usage;
you're depending on undocumented (and untested, AFAIK) behavior.

I remember when SCons first came out I had the same reaction to
Import/Export using strings for the names of the envs, but I've gotten
used to it and it makes sense to me now. I'm not sure how you could
get all the flexibility of Export/Import without string names.

--
Gary


More information about the Scons-users mailing list