How can I reference cousin objects in scons? - scons

Question

How can I get objects that are built under separate SConscripts in my program correctly? I have a directory structure that looks similar to this:
SConstruct
|
|---- moduleA
| |
| ----Sconscript
| ----src
| |-- sourceA1.cpp
| |-- sourceA2.cpp
| ----build
| |-- sourceA1.o
| |-- sourceA2.o
|
|---- moduleB
| |
| ----Sconscript
| ----src
| |-- sourceB1.cpp
| |-- sourceB2.cpp
| ----build
| |-- sourceB1.o
| |-- sourceB2.o
|
|---- Program
|
----SConscript
----src
| -- main.cpp
moduleA's SConscript might look like this (moduleB is similar):
moduleEnv = env.Clone()
srcFiles = [ 'src/sourceA1.cpp', 'src/sourceA2.cpp' ]
obj = moduleEnv.Object(srcFiles)
In my Program, I need to use the object files to build. I don't want to use a bunch of hard coded paths to do this. Is there any way that the SConscript for the program can reference the objects of the modules?
Program's SConscript
progEnv = env.Clone()
objectsList = [ Objects from the modules ] # Is this possible, or is the a better way?
prog = progEnv.Program('myprogram', [ objectList, 'src/main.cpp'])

Answer 1

Any variable you define in an SConscript can be Export()ed so other SConscripts can pick it up (via Import()). The export space is global. In your example for moduleA's SConscript, after the call to Object, obj holds a list of Nodes (even though in the majority of cases that list has only one entry - here it would be two). A node is SCons' internal representation of an object participating in the build, and it's prefectly fine to use those to refer to built objects - and means you shouldn't have path problems, because SCons always knows how to locate a node. You can collect those and export them. I would probably do one per module, so perhaps:
obj = moduleEnv.Object(srcFiles)
moduleEnv.Export(moduleAobj=obj)
Then your main SConscript can look like:
SConscript("moduleA/SConscript")
Import("moduleAobj")
SConscript("moduleB/SConscript")
Import("moduleBobj")
objects = Flatten([moduleAobj, moduleBobj])
that's untested but hopefully a starting point, at least.