Configure SCons for a hierarchical source, but the only goal

Question

I have a C ++ / Python project that I was working on, and still relied on Visual Studio to manage assemblies. Now I want to automate the build process, I hope it includes support for several platforms (all this is standard C ++ / Python) and I think that SCons can be a tool to do this work.

Several directories use a lot of source files, but a typical (stereo) example looks like this:

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 is only one purpose. (The hierarchy maps to the namespaces used in the code, but this is unnecessary for the purpose of this question.)

My question is: what is the best way to structure SConstruct and SConscript files? I read the SCons documentation, in particular the Hierarchical Assemblies section, and the idea of ​​using multiple SConscript files with matching SConscript calls. Everything seems clear and especially neat. However, this seems to be intended for a hierarchy with several goals. Can I use the same function where there is only one purpose?

(I really thought about the top-level SConstruct / SConscript file, at least for the library in question, listing the entire source file using subdirectories, but I don’t “feel” the best way to do this. Perhaps this is the way forward?)

Thanks a lot in advance for any advice / understanding.

Answer 1

There is nothing wrong with listing all the source files in a single SConstruct file. Hierarchically structuring SConscripts is also fine, but you will need to return objects from each level, which will be a little silly:

 # SConscript, for example sources = ["bar1_1.cpp", "bar1_2.cpp", ...] objects = [env.Object(x) for x in sources] Return(objects) # SConstruct (top-level) directory_1_objects = SConscript("directory_1/SConscript") directory_2_objects = SConscript("directory_2/SConscript") program = env.Program("magical_wonders", [directory_1_objects, directory_2_objects]) 

In my opinion, the only raster level of all source files in a particular binary format is preferred for this, which requires more wiring when changing the file hierarchy.

Answer 2

I have used a hierarchical solution several times, similar to the one you are describing. I chose this solution:

in 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 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 subtle control over the environment in each package, and with the clever use of the * site_scons * folder, you can prevent duplicate lines from repeating over and over for each sconscript. Another advantage of this approach is that scons files reflect the design. I also prefer to use Glob to collect cpp files, allowing me to add and delete files as I like, without editing any build files for such trivial operations.