[Scons-dev] Lightning talk about parts

[anatoly techtonik]

On Mon, Mar 18, 2013 at 7:42 AM, William Deegan
<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 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 listScons-dev at scons.orghttp://two.pairlist.net/mailman/listinfo/scons-dev

>

>

>

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

> http://two.pairlist.net/mailman/listinfo/scons-dev

>

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20130318/199940c8/attachment.html>