Re: compile scons submodule

Hi Gary,

Thanks for your help. I'm not entirely done yet, but I decided
to leave the submodule's SConstruct/SConscript untouched,
but created a sub-directory with a single SConscript for the
submodule compilation, which copied and slightly modified
lines from both submodule SConstruct/SConscript files.
Once I have it working correctly, I might have to rethink
if I can just use Python's import to get functionality from
both files (I might have to rewrite them to make that easier),
so I do not have to manually merge lines again and again.
Anyway, thanks for your suggestions!

Cheers,
Jan

On 2/16/23, 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