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
Export("foo", "bar", "baz")
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
env = Environment(foo = 1, bar = 2, baz = 3)
But the underlying flexibility in the mechanism is there either way.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk