[Scons-users] compile scons submodule

[Jan Walter]

Hi Bill,

Thanks.

> This would require a reasonable understanding of the existing SConstructs.

Yup, I think there is no way around it. It would be nice to see a
tutorial at some
point how to organize SConstruct/SConscript scripts for reuse with submodules
in mind. If I find a good solution I might write such a tutorial
myself one day ...

Cheers,
Jan

On 2/16/23, Bill Deegan <bill at baddogconsulting.com> wrote:
> If you migrate the logic in the subprojects SConstruct into a SConscript
> suitable for inclusion in both the subprojects SConstruct, and the top
> level project's SConstruct.
>
> This would require a reasonable understanding of the existing SConstructs.
>
> On Thu, Feb 16, 2023 at 7:53 AM Gary Granger <granger at ucar.edu> wrote:
>
>> 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.
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>