What difference in effect is there, if any, between these?
SConscript('subdir/SConscript')
env.SConscript('subdir/SConscript')
I initially wondered if this affected the called SConscript's DefaultEnvironment, so I tried this experiment:
SConstruct:
env = Environment(CC='my_cc')
SConscript('SConscript', exports={'program':'p1.c'})
env.SConscript('SConscript', exports={'program':'p2.c'})
SConscript:
Import('program')
Program(program)
Result:
$ scons -n -Q
gcc -o p1.o -c p1.c
gcc -o p1 p1.o
gcc -o p2.o -c p2.c
gcc -o p2 p2.o
But, as you can see, the construction environment used in SConscript seems unaffected.
If you simply write:
Program('main','main.cpp')
SCons will use what is called the "DefaultEnvironment" internally. It was added for people, like starting developers in Bioinformatics, when they don't need to work with special environment settings...or don't have several different environments in their builds.
It makes typing a little less verbose, but you're stuck with one Environment. However, one can always freely mix the DefaultEnvironment with self-defined ones...it's just a matter of taste.
But what's important to note is, that the DefaultEnvironment and additional Environments are not automatically related or connected, regarding their settings. Finally, the DefaultEnvironment can also be accessed directly by using:
import SCons.DefaultEnvironment
SCons.DefaultEnvironment(tools=[])
env = Environment(...)
which here has the effect of stopping SCons from searching for tools/apps in the system twice...once for the DefaultEnv, and once for your special environment. Internally, a command like "Program()" is simply a wrapper for "SCons.DefaultEnvironment.Program()"...that's all there is to it.
Based on all of the above, the SConscript() method is available in any Environment...and it should always be safe to include other build spec files with a simple
SConscript('...')
, which is also the method I prefer personally.