[Scons-users] Provide default Import to SConscript

[Hua Yanghao]

Hi Gary,
I like your idea of making it into namespaces, which is more pythonic also.
Consider in SConscript, which should be considered as equally as any
python script, it will be good if we can do:

    import scons
    scons.Import()/Environment()/...

    import mymodule
    mymodule.xyz()...

And if we have this "default_import" capability then user can actually
decide not to import SCons method by default at all with
"default_import=None", so a pattern on SConscript can be enforced and
user still have the possibility to explicitly import them.

However here actually I really don't want to treat SConscript as any
other python file out there, and rather consider it is special and it
is even a domain-specific script (happens to be a python script too).
And you should define your domain's specific environment that is
available by default. Exactly like what SConscript() now is already
doing, to make a few method available by default, so in SConscript you
can cut the cheese and get to the point directly:

    usw_files("elf", [a.c, b.c, c.c, x.S, ...])
    usw_files("hdl", [a.v, b.v, c.v, ...])

And that's it, so you can build domain specific SConscript that meets
your needs to simplify how a module can be created, and building a
build framework that is way easier to use than default SCons. I still
remember when I first try to use scons there are many concept/details
to catch up and it is not actually as easy to use as kbuild system. I
actually believe scons should have build more than just the core and
tools, but rather to provide a build framework that end user can
directly use without any hurdles: write a one line SConscript for a
module, include that module in a top level module list SConstruct will
read, and you are done (just like kbuild system).

The other alternative is like Spencer suggested to wrap around another
file, say "Makefile", where it is read and a new SConscript file is
generated with the content in Makefile inserted after the explicity
imports. I try to avoid this indirect step as my project was pure 100%
scons-based and for old libraries I actually manually create a
SConscript for it (I even created a SConscript to build micropython
entirely.).

The reason I really love python is you really don't need to type that
much and can get things done, and I try to stay with that principle
whenever I can.

I don't find much introduction of the design concept of SCons internal
so it may take a while for me to fully understand its design and see
what is the best way to implement this. Or even better if more
experienced developer sees the value and jumps in to help out ;-)

Best Regards,
Yanghao

On Tue, Feb 20, 2018 at 8:36 PM, Gary Granger <granger at ucar.edu> wrote:
> 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
>
>