[Scons-users] how to properly share an output folder with two subfolders?

[Bill Deegan]

Gary - well said.

I typically use "SConsian" instead of "scons-onic" ;)

On Fri, Jun 5, 2020 at 8:28 AM Gary Granger <granger at ucar.edu> wrote:

> Hi Dagg,
>
> I just tried that out because I wasn't sure.  If you pass an export in the
> SConscript() exports parameter, then it is only available in that
> SConscript.  So given this call in the SConstruct:
>
> SConscript('a/SConscript', exports = 'env')
>
> and this call in 'a/SConscript':
>
> SConscript('b/SConscript')
>
> You cannot Import('env') in '#/a/b/SConscript'.  If you want to make a
> symbol available everywhere easily, then just use Export() directly.  You
> can use this code in SConstruct:
>
> OUTPUT = env.Dir("#/output")
> env['OUTPUT'] = OUTPUT
>
> Export('env')
> Export('OUTPUT')
>
> SConscript('a/SConscript')
>
> Then *all* other SConscript files can import those symbols.  This works
> in 'a/b/SConscript':
>
> Import('env')
> print(env.subst("output directory: $OUTPUT"))
>
> Import('OUTPUT')
> print("output directory: %s" % (str(OUTPUT)))
>
> I gave an example of also exporting only the output directory variable, if
> that's all you need everywhere.  You obviously don't need both exports.
>
> Finally, you can also export any python symbol, not just Environments.  So
> we Export tool functions from elsewhere in the source tree, because I think
> tools are more "scons-onic" (can I say that?) and they easily allow
> composition in environment setups.  Here's how that might look for making
> the shared output available everywhere.
>
> In SConstruct:
>
> def setupoutput(env):
>     env['OUTPUT'] = OUTPUT
>
> Export('setupoutput')
>
> Then in any SConscript where you need the OUTPUT variable, such as
> a/b/SConscript:
>
> envb = Environment(tools=['default', 'setupoutput'])
> print(envb.subst("output directory: $OUTPUT"))
>
> Where the whole tool composition approach really shines (I think) is
> within a large source tree, where a library subdirectory can both define
> the builders for the library and also export a tool function which adds the
> build dependencies for that library to an environment.  Then any other
> components in the source tree which depend on that library can just apply
> the tool to their Environment.  All the components which need that library
> do not even need to know where in the source tree that library lives (as
> long as the library SConscript is loaded first to define the tool
> function), and the library can change it's dependencies just by changing
> the tool function, without modifying any other SConscripts in the tree.
>
> Hope that helps,
> gary
> On 6/5/20 12:17 AM, daggs wrote:
>
> Greetings Gary,
>
> thank you for the detailed explanation, looks like the first solution is
> what I need.
> I have one more question in relation to the solution, lets say I call
> another SConscript from within a/SConscript, I need to pass the same args
> to it which passed to a/SConscript when it was called in SConstruct?
>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20200605/9ef95eee/attachment.html>