I have an SCons-based project that has a rather specialized SConstruct file (due to CUDA), let's call it project A. I am using it as a submodule for another project I am working on we can call project B that is also going to have some rather peculiar compilation requirements (due to MEX).
I'd like to leave project A effectively untouched as it is a common library in my group. How do I get project B to get all of the include, library, etc. information that it needs in order to "compile through". In CMake this would effectively just be a combination of add_subdirectory() and target_link_libraries(). Is there an equivalent concept in SCons or is an SConstruct more strictly standalone (can't be called by another SConstruct)?
(this was too long for a comment, not sure it's an "answer"...)
SConstructs are unique top-level things, but then again, they also aren't - you can call any file when you call SConscript(), including one named subdir/SConstruct, as long as the latter is structured in a way that has that make sense, and having A Export() things that projects that called it would be interested in Import()ing.
There's also nothing to stop you from writing a really minimal SConstruct for A which does only things that might be unique to building A standalone, and all the real (common) work is done by an SConscript which A's SConstruct calls, but which B's SConstruct can also call.
Or, you could add a step to A that writes all the variable information you think project B needs into a file, say exports.py in the form of assignment statements, and have B read that in with a Variables(files="exports.py") call - this is a bit like doing Export and Import but across the boundary of scons calls. If the file doesn't exist, assume you have to make a call to scons to run A's build, so the file serves as the sync point for two independent builds.
You might also be able to do something with the ParseConfig function, if you write a script to call which munges the information from A into a form B can consume.
All of these do imply some changes to A's build, however. They should be harmless from A's viewpoint: writing a file or exporting some variables is a throwaway operation unless someone is listening for those - assuming A's build is suitably clean.
Maybe some thoughts from here (though not exactly the same case) might be applicable? https://github.com/SCons/scons/wiki/SconstructMultiple