Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

SCons setup for hierarchical source but single target

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.

like image 296
bitcyber Avatar asked Jan 10 '12 20:01

bitcyber


1 Answers

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.

like image 76
daramarak Avatar answered Sep 28 '22 15:09

daramarak