I should add that I think there are a number of different ways to do a declarative format as well, the json format is just another way that could be supported
Jason From: Kenny, Jason L Sent: Sunday, March 17, 2013 3:20 PM To: 'anatoly techtonik'; SCons Development Subject: RE: Lightning talk about parts Thanks. That talk went fast.. I have to go find the video.. I do have a design given the Parts idea in how I would define a more declarative format using @declorators. This would greatly help start up times and I believe memory given we can partition what set of node we need to process.. anyways I should write something up minus what I have in an internal OneNote page. Jason From: anatoly techtonik [mailto:[email protected]] Sent: Sunday, March 17, 2013 4:50 AM To: SCons Development; Kenny, Jason L Subject: Lightning talk about parts 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] http://two.pairlist.net/mailman/listinfo/scons-dev
