Re: [jamboost] Boost.Build V2, load behaviour part 2.

From: Steven Knight (knight_at_[hidden])
Date: 2002-04-01 02:05:34

> We could make a builtin that enumerates the names of all variables in a
> module so we can poke all the values from the project-root into the
> jamfiles. They would then be separate copies... OK, I am provisionally
> convinced that you made the right design choice. As long as we give
> people a way to make their own modules with true namespace protection
> (and we have done that), I think you're right that all
> projects/subprojects should share variables and rules.
> 
> [Steve K., I'd appreciate hearing from you about this - how does Scons
> deal with variable/function scoping in large, multi-sconsfile
> projects?... oh, its the environment which carries this info across
> Sconsfiles, right?]

Usually, but not necessarily.

Each SConscript has its own namespace, and you can either explicitly
export a set of variables when you "call" a subsidiary SConscript file:

SConscript('subdir/SConscript', exports = ["foo", "bar", "baz"])

Or you can call an Export() method that arranges for a specific set of
variables to be exported to all SConscript() calls (until the next call
to Export()):

Export("foo", "bar", "baz")
SConscript('subdir/SConscript')

Subsidiary SConscript calls don't get these variables automatically,
they have to explicitly Import() them to use them:

Import("foo", "bar", "baz")

This is to minimize the chances of unintended side effects in remote
corners of the build due to a variable change.

In practice, it's generally easier to wrap up most of these variables
in a single exported Environment, rather than Export() a long list of
variables:

env = Environment(foo = 1, bar = 2, baz = 3)
SConscript('subdir/SConscript', "env")

But the underlying flexibility in the mechanism is there either way.

--SK