[Scons-dev] Lightning talk about parts

[William Deegan]

On 03/18/2013 12:01 AM, anatoly techtonik wrote:

> On Mon, Mar 18, 2013 at 7:42 AM, William Deegan 

> <bill at baddogconsulting.com <mailto:bill at baddogconsulting.com>> 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 

> <http://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/


Fairly certain each projects IRC channel would be a good place to start?
I'll be onsite so if you'd like to connect with particular project, let 
me know and I can go ask them.
I'll be on #scons IRC and probably #buildbot

-Bill

>

>     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

>>

>>     --

>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20130318/4d0947d5/attachment.htm>