[Scons-users] Provide default Import to SConscript

[Bill Deegan]

Yanghao,

SCons is meant to be a python based make replacement.

What your suggesting is probably more along the lines of Parts? (Jason)
(Which is build on top of SCons).

So if I understand properly, you want to add an alternative version of
SConscript where the files would be presented and entirely different set of
globals to work with?

-Bill



On Wed, Feb 21, 2018 at 4:58 AM, Hua Yanghao <huayanghao at gmail.com> wrote:

> 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
> >
> >
> _______________________________________________
> 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/20180221/03ece244/attachment-0001.html>