[Scons-users] Provide default Import to SConscript

Wed Feb 21 11:27:30 EST 2018

So I was going to suggest the idea of namespaces as well.

History wise Steve though namespaces are to complex. to have in SCons. As far as Parts I have code we could add to Scons. I think I want to tweak it a little more ( a fine tuning easier for usage)

In Parts I have some code https://bitbucket.org/sconsparts/parts/src/3258a0ff867c5c48faac46993837a05a13d5e474/parts/common.py?at=master&fileviewer=file-view-default#common.py-74

this namespace object allows one to add an object that will be seen in the environment under a different value. For example

env['myspace']=namespace(dict(one=1,hello="world"))
then you can say:
env['myspace'].one
or env['myspace']['one']
I think env.myspace.one will work as well

you can also do

env.subst("${myspace.hello}")  -> "world"

This object also has some logic to help with Clone() calls to make sure stuff gets duplicated when it should.

I have logic for depends handling as well to allow exporting from one Part and importing them in another, with control if the custom values are added to the "public" space or not. By public, I mean adding it to top-level environment, vs it being imported in a namespace of the part. I should also state I want to but have not had time to do a refactor to make this better. The current code work via passing around string "mapper" objects that allow this data to be passed by the subst engine in SCons

ie Parts A:

env.ExportItem("mykey","myvalue")

in part B

DependsOn([
    Component("A",requires=REQ.A(public=True)),
])

This would make the value in an environment so you can say:
env.subst('${mykey}')

this will return "myvalue" given Part A was loaded before B ( otherwise the value of A is not known yet)

in both the case of being public or not this value is mapped to
env['DEPENDS']['A']['myvalue']

which is a namespace so you can say
env.subst('${DEPENDS.A.myvalue}')

There is more you can so with the Depends system in Parts.. my goal is to get time to change the loading logic to allow me to pass objects straight and remove the mapping logic. I can try to answer that if you have questions

either way the namespace object I think is what you are looking for. I think it would be a good addition to SCons

Jason

________________________________
From: Scons-users <scons-users-bounces at scons.org> on behalf of Bill Deegan <bill at baddogconsulting.com>
Sent: Wednesday, February 21, 2018 9:38 AM
To: SCons users mailing list
Subject: Re: [Scons-users] Provide default Import to SConscript

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<mailto: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<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmymodule.xyz&data=02%7C01%7C%7C2e9037112b914243bbee08d5794122a2%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636548243006635246&sdata=dGhKXXyAeobqJSFW86hhUiFPCzXtvJFOMWCK%2BBbMWO4%3D&reserved=0>()...

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<mailto: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<mailto:Scons-users at scons.org>
https://pairlist4.pair.net/mailman/listinfo/scons-users<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&data=02%7C01%7C%7C2e9037112b914243bbee08d5794122a2%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636548243006635246&sdata=BV1NRIn%2B%2B4C93DID4EBOzY4RQS3wWKvbU%2FCUx0ZAx54%3D&reserved=0>

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