Right. I thought about JSON just because I was exploring existing solutions and was reading about `gyp` https://code.google.com/p/gyp/ at that moment.
P.S. Hey, Jason. I've just noticed that I mixed up your name with the surname. Sorry about that. It is interesting to read that 'Kenny' is actually a very common surname in Ireland. But.. given that it goes first in email address, I will not be surprised if many people mix it up. =) -- anatoly t. On Sun, Mar 17, 2013 at 11:22 PM, Kenny, Jason L <[email protected]>wrote: > 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
