On Mon, Mar 18, 2013 at 7:42 AM, William Deegan <[email protected]>wrote:
> Bummer. > I'm at pycon. > Didn't know any other SCons folks are here. > > Anyone sprinting? > Only if remotely. I planned to sprint on bugs.python.org Roundup to merge patches upstream, but since there is nobody around at PyCon to organize people there, I probably switch to something else - outreach project seems actual in this context, but I am not sure if I can get in touch with people sprinting from online. There doesn't seem to be any IRC channel for that https://us.pycon.org/2013/community/sprints/projects/ On 03/17/2013 02:50 AM, anatoly techtonik wrote: > > Congratulations to Kenny with his lightning talk about parts on PyCon! =) > > Now I understand what's going on with it a little bit more and I like > the stuff. It will be awesome to have these slides with examples online and > linked from SCons website. http://parts.tigris.org > > I have a long standing idea of teaching SCons to understand the > declarative format (like JSON) that can be used to describe and compile > simple dependencies, such as zlib: > > http://wiki.openttd.org/Compiling_on_Windows_using_MinGW#Compiling_zlib > > Why the need of the declarative format? To know the inputs and outputs > of the package like zlib and connect them to the inputs and outputs of > other dependencies. Like I know the dependency graph of the package, but > when I look into SCons - there is no way to get that high-level overview of > these. Even low level dependency tree requires a dry run. Of course, the > SCons powers are not squeezable into such format and it is impossible. But > for the purpose of clarity and studying dependency problems, such format > would be very welcome. > > For example, there are no _dependency level input_s for zlib - it is > self-contained, but there are can be several outputs. Required output is > affected by some generic (or specific) condition. As a user, I only know > that a zlib is a library, and it is pretty dark to know the shared/unshared > details. I understand that parts already cares about these underlying > details automatically. > > So, the question - is it technically feasible with parts to fulfill this > scenario: > - take zlib description in JSON format > - show input and output dependencies of the package > - show user level info about possible outputs > - show low level switches that affect the outputs > - show how these switches are connected to other parts (dependencies), > because some dependencies set these switches and they can not be changed > - download and compile > > In the end it might look like (sorry, not time to polish this): > > [switches] > +------+ > +------+ | > +------+ | | > | | | [outputs] > [inputs] +----+-+-+-+ +-----------+ > +----+ +--shared-+ | | > | part | +=====+ part | > shared ---+ +==static=+=====+ | | > lib +----------+ ^ +-----------+ > input | > | > + > line powered when parts > are connected > > -- > anatoly t. > > > _______________________________________________ > Scons-dev mailing > [email protected]http://two.pairlist.net/mailman/listinfo/scons-dev > > > > _______________________________________________ > Scons-dev mailing list > [email protected] > http://two.pairlist.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
