CODEWITHSUNDEEP
c++cscons
Bob
Bob

Reputation: 415

SCons: expanding library dependencies recursively

I am currently using an SCons-based build system that I am not repsonsible for maintaining but can provide input to the maintainer.

One of the problems it has is in dealing with dependencies between C++ source packages. In the system, each source package is built to a DLL on Windows or shared library on Linux.

Let's say that package A has include dependencies on packages B and C. B and C are specified in package A's SConscript. This is fine. The DLL for package A will also be linked against DLLs for B and C. This also is fine since any link dependencies that B and C have will already have been resolved when those DLLs were built.

The complication comes with packages that have unit tests associated with them. Here we need to know the full, recursively expanded, list of library dependencies, for two main reasons:

  1. Building a unit test involves creating a script that sets up the PATH and invokes the executable. An entry needs to be added to the PATH for each run time dependency.
  2. Linking a unit test executable on Linux needs the full, expanded, list of library dependencies. This is different from Windows where the DLL linking model means that indirect dependencies are already accounted for.

We don't want to have to explicitly specify the fully expanded list of dependencies because that is overly verbose and a maintenance problem.

The current system, which is still buggy, does require us only to have to specify direct dependencies in the package SConscripts, but resolves the indirect dependencies via Python code in the SConstruct. This code opens and parses the SConscript files and builds up a map of dependencies from the information thus extracted. This approach feels wrong. Intuitively, I feel that there ought to be a way to do this more naturally using native SCons facilities but I am not sufficiently familiar with SCons to be able to suggest a better way. Is there a better way and what is it?

Upvotes: 2

Views: 1197

Answers (1)

Hank
Hank

Reputation: 547

It's a hack, but I just keep a variable in my top-level environment that gets exported to all my SConscripts, and every time one of the SConscripts needs a new library, I just do this:

env.Append(TOPLEVEL_LIBS = ['somelib'])

This way, env['TOPLEVEL_LIBS'] contains all of the libraries necessary, and it's accessible from any SConscript.

Upvotes: 1

Related Questions