I have a C++/Python project that I've been working on and so far have relied on Visual Studio to manage the builds. Now I want to automate the build process, hopefully include multiple platform support (it's all standard C++/Python), and think SCons could be the tool to do the job.
There's a lot of source files involved, in multiple directories, but a (stereo)typical example is as follows:
foo.lib
directory_1
bar1_1.cpp
bar1_2.cpp
... etc. ...
directory_2
bar2_1.cpp
bar2_2.cpp
... etc. ...
So, in other words, the source files are in a hierarchy, but there's only a single target. (The hierarchy is matched in the namespaces used in the code, but this is superfluous for purposes of this question.)
My question is: What's the best way to structure the SConstruct and SConscript files? I read the SCons documentation, particularly, the Hierarchical Builds section and the idea to use multiple SConscript files with suitable 'SConscript' calls. All seems clear, and particularly neat. However it would seem this is intended for a hierarchy with multiple targets. Can I use this same feature where there's only one target?
(I did think of a top level SConstruct/SConscript file, at least for the library in question, listing all the source file with subdirectories, but doesn't "feel" the best way to do it. Maybe indeed this is the way forward?)
Many thanks in advance for any advice / insight.
I have several times used a hierarchical solution much like the one you describe. I have chosen a solution like this:
in the SConscript:
#/bar/SConscript
Import("env")
env = specialize_env_for_this_subpackage()
myfiles = Glob(*.cpp)
apply_any_exclusions(myfiles)
myobjects = env.Object(myfiles)
Return(myobjects)
then in the SConstruct:
#SConstruct
env = construct_general_environment()
subpackages = ["foo","bar","baz"] #or perhaps call your own find_subproject() function
objects = SCons.Node.NodeList
for package in subpackages:
pack_objects = env.SConscript(os.path.join(package,"SConscript"), exports = env)
objects.extend(pack_objects)
program = env.Program("myprog",objects)
Default(program)
Then you have fine tuned control over the environment in each package, and with clever use of the *site_scons* folder you can prevent repeating the same lines over and over for each sconscript. Another advantage with this approach is that the scons files reflects the design. I also prefer using a Glob to gather cpp files, allowing me to add and remove files as I like, without editing any build files for such trivial operations.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With