[Scons-users] Provide default Import to SConscript
bill at baddogconsulting.com
Wed Feb 21 10:38:11 EST 2018
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?
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
> import mymodule
> 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
> 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,
> 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
> > 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
> > 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,
> > the developer would have complete control over the namespace. I don't
> > 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
> > 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,
> > more wordy, and perhaps it's the wrong approach if the concept is to
> > 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
> > SCons symbols in the SConscript scope? That could be very powerful,
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Scons-users