Re: compile scons submodule

IMHO basically you'd set up the Environment()(s) in the SConstruct and then
call the SConscript to call all the builders, possibly clone/update the
passed environment to update CPPDEFINES, CPPPATH, LIBPATH, perhaps others.

but there's really not a great cookie cutter solution for all such.

Depends how the top level build (and potentially other submodules) use the
build product from submodule #1..


On Mon, Feb 20, 2023 at 2:55 AM Jan Walter <[email protected]> wrote:

> 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 <[email protected]> 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 <[email protected]> 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
> >> [email protected]
> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
> >>
> >
> _______________________________________________
> Scons-users mailing list
> [email protected]
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

_______________________________________________
Scons-users mailing list
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users