[Scons-users] Provide default Import to SConscript

[Gary Granger]

Hello Yanghao,

I've been following this thread since I think it's an interesting idea. 
SCons allows so much extension and customization, but usually (by common
practice and by design) that extension happens by adding builders and
methods to an Environment.  However, it does make sense that maybe there
should be a way to extend the symbols available by default in the
SConscript scope.

The problem with that, though, is you might collide with what SCons
wants to put in the SConscript scope, and it's reasonable to give SCons
exclusive control of that with Import().  Instead, what if there were a
namespace for exported symbols that was always available in a
SConscript, without Import():

For example, one SConscript exports a symbol as usual:

    Export('xyz')

Then in the other SConscripts the symbol can be accessed like so:

    Exports.xyz()

Would that be convenient and non-repetitive enough?  This would mean no
Import() would be required to access exports, but the exports would be
qualified by a namespace which was always available at SConscript scope,
and the developer would have complete control over the namespace.  I
don't know how hard that would be to implement, but I assume with python
it must be possible.

Note that right now I think you can get similar functionality by
extending DefaultEnvironment(), since DefaultEnvironment is always in
SConscript scope, and it can be extended in the conventional ways:

    DefaultEnvironment().AddMethod(xyz, "xyz")

And then everywhere else:

    DefaultEnvironment().xyz()

Someone please correct me if that doesn't sound right.  Either way,
that's more wordy, and perhaps it's the wrong approach if the concept is
to extend the SConscript scope and not an actual Environment.

I also considered whether Export() is a better place to implement this
'default_import' functionality, since writing
SConscript(default_imports=[...], ...) could get repetitive for lots of
SConscripts.  For example, allow an Export'ed symbol to be added to a
"global imports" list:

    Export('xyz', global=True)

I like that idea too, but I understand that people may want finer
control over the default imports of each particular SConscript as it's
loaded.

I've never thought of this before, but what if someone Import()s a
symbol which collides with a SCons symbol, like Library?  Is it possible
to replace SCons symbols in the SConscript scope?  That could be very
powerful, which could make it a bad idea. :)

Just some ideas I wanted to share.  Thanks,
gary

On 02/20/2018 01:29 AM, Hua Yanghao wrote:
> Hi Bill,
> Unfortunately my source tree cannot be made public for now. I am
> trying to get the core of it public in several month from now ...
>
> The thing is, in SConscript there are already quite a few object made
> available by default: Import, Return, ...
> The best way would be change that static list into a dynamic one. I
> always believe a good design should provide mechanism, not policy. and
> in this case the mechanism is "make some object available in
> SConscript", and the policy is "which one should be there". The policy
> part is better left for the user/application to decide. I will try to
> see how far I can go and keep you posted and let's debate again once I
> got some patch available.
>
> Best Regards,
> Yanghao
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20180220/cbc15b3a/attachment.html>