[Scons-users] compile scons submodule

[Gary Granger]

Hi Jan,

You can read the submodule's SConstruct file as if it were a SConscript, 
using something like this:

SConscript("external/another_project/SConstruct")

SCons does not care that the file is not named SConscript.  However, in 
that case the top directory, '#', will be the directory of the top 
SConstruct, and probably another_project/SConstruct is written expecting 
'#' to be the another_project directory.  However, it's possible to 
write the SConstruct file so that it doesn't depend on '#'.

Another approach we've used is to just create an actual SConscript file 
for the submodule, and share as much code as possible with the 
SConstruct.  Sometimes that means using a tool file, and sometimes the 
SConstruct file just contains a SConscript() call to the submodule's 
SConscript file.  That way the submodule can be built on it's own using 
the usual 'scons -u', but it also works to call the SConscript file from 
a parent project.

Another thing that has worked well for us is to create a scons tool file 
for the submodule, eg, another_project.py.  That tool creates the 
builders for the submodule, but then it also adds the library and 
cpppaths for that submodule to the calling environment.  That way other 
Environments anywhere else in the parent source tree can just apply that 
tool to build against another_project, eg, env.Tool('another_project').  
You just have to add the submodule directory to the tool path when the 
Environment is created.  We have a mechanism which goes a little further 
and actually scans the source for tool files when a tool is requested.  
With that, the top project does not need to know where the submodule 
even exists in the tree, it's enough for an Environment to apply the 
tool for that submodule name.

The problem with both a SConstruct and SConscript file in a submodule is 
that if you try to run 'scons -u' in the submodule as part of a larger 
project, that will only find the submodule SConstruct and only build 
that.  One workaround for that is to not use the SConstruct at all, just 
a SConscript.  Then run 'scons -f SConscript' when you really want to 
build just the submodule.

Here is a submodule project which uses the tool file and SConscript file 
approach instead of a SConstruct file: https://github.com/NCAR/logx.  
The tool searching and loading is provided by our extensions to SCons: 
https://github.com/NCAR/eol_scons, but I don't think you need that if 
you just add another_project to the tool path.

Hope that helps,
Gary

On 2/16/23 03:54, Jan Walter wrote:
> Hi,
>
> I'm not really that familiar with scons (yet) but I inherited a large
> project which uses scons.
>
> It uses a SConstruct file in it's root directory, which seems already
> pretty complicated,
> and a custom.py file which allows to set some environment variables to
> find other
> libraries and/or executable files.
>
> Anyway, I would like to use git submodule to create a clone of an
> existing project,
> which also uses scons and a related SConstruct file to compile a
> library, which is used
> in the main project. So far we compiled the library for each platform
> separately and the
> main SConstruct file simply knows how to link the external library
> into other libraries.
>
> So it looks like this:
>
> $ tree
> .
> ├── custom.py
> ├── external
> │   └── another_project
> │       └── SConstruct
> └── SConstruct
>
> Right now I could copy the custom.py (or create a softlink to it),
> change into the external/another_project/ folder and compile
> the library there using scons. What's the easiest way to adjust
> the main SConstruct file to do this for me, before some other
> libraries of the main project get compiled, which have to link
> in the library from the submodule.
>
> Any help with that would be appreciated.