[Scons-dev] Lightning talk about parts
anatoly techtonik
techtonik at gmail.com
Mon Mar 18 02:54:40 EDT 2013
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 <jason.l.kenny at intel.com>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:techtonik at gmail.com]
> *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.****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20130318/99fbe6f7/attachment.htm>
More information about the Scons-dev
mailing list