I am not, I have to get some stuff done at work while I am out here for a few days. It would be great to meet up while more than one of us are in San Jose area.
Jason From: [email protected] [mailto:[email protected]] On Behalf Of William Deegan Sent: Sunday, March 17, 2013 11:43 PM To: [email protected] Subject: Re: [Scons-dev] Lightning talk about parts Bummer. I'm at pycon. Didn't know any other SCons folks are here. Anyone sprinting? -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 -- anatoly t. _______________________________________________ Scons-dev mailing list [email protected]<mailto:[email protected]> http://two.pairlist.net/mailman/listinfo/scons-dev
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
