CODEWITHSUNDEEP
buildscons
zmartin
zmartin

Reputation: 211

Scons Hierarchical Build

I've gone through the example scons builds here and have found them wanting in providing a solution that fits my project.

The structure is as follows:

root/
   Module_A/
      include/
         foo.h
         bar.h
      src/
         foo.cpp
         bar.cpp
   Module_.../

Every module follows the same structure, an include folder for all the .h's and a src file for the cpps. Each module builds into a shared object. There is no executable.

Modules have cross dependencies. For instance Module_A is the logging mechanism and it is used in modules B, C, D, etc. Likewise, Module_B is the Configuration loader, which is used in several other modules. And Module_C would be the IPC module, used in almost each module listed. Lastly, Module_D is the command center and links against EVERY other module (literally).

I am interested in replacing the current setup we have of using recursive make to build the project. I am trying to build the sconstruct and SConscripts necessary to do so, but I am very new to even make, let alone scons.

I am interested in turning each Module's .cpp and .h into a .so and to have its dependencies resolved automagically as is done with make now.

In the SConscript, I currently use glob to get the *.cpps and then include the module's './include' in the CPPPATH. I have used

env.SharedLibrary(CPPATH='./include', source= (list of the cpps))

But since this depends on other Modules, it will not work, stating the other module's functions that are used are "not declared".

How do I go about getting this kind of complex structure to build using a hierarchical scons setup?

Upvotes: 2

Views: 584

Answers (1)

Brady
Brady

Reputation: 10357

This should be quite easy to do with SCons. You'll probably want a SConscript script at the root of every module. These will all be invoked by a SConstruct script located at the root of the entire project.

If I understand the question correctly, the problem of the dependencies between the modules can be solved by correctly specifying the include paths of all of the modules. This can be done once in an Environment created in the SConstruct, which should then be passed to the module SConscript scripts.

Here's a brief example:

Sconstruct

env = Environment()

# Notice that the '#' in paths makes the path relative to the root SConstruct
includePaths = [
    '#/Module_A/include',
    '#/Module_B/include',
    '#/Module_N/include',
]

env.Append(CPPPATH=includePaths)

SConscript('Module_A/SConscript', exports='env', duplicate=0)
SConscript('Module_B/SConscript', exports='env', duplicate=0)
SConscript('Module_N/SConscript', exports='env', duplicate=0)

Module_A/SConscript

Import('env')

# Notice the CPPPATH's have already been set on the env created in the SConstruct
env.SharedLibrary(target = 'moduleA', source = ModuleA_SourceFiles)

Module_B/SConscript

Import('env')

# Notice the CPPPATH's have already been set on the env created in the SConstruct
env.SharedLibrary(target = 'moduleB', source = ModuleB_SourceFiles)

Module_N/SConscript

Import('env')

# Notice the CPPPATH's have already been set on the env created in the SConstruct
env.SharedLibrary(target = 'moduleN', source = ModuleN_SourceFiles)

Upvotes: 6

Related Questions