On 03/18/2013 12:01 AM, anatoly techtonik wrote:
On Mon, Mar 18, 2013 at 7:42 AM, William Deegan
<[email protected] <mailto:[email protected]>> 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
<http://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/
Fairly certain each projects IRC channel would be a good place to start?
I'll be onsite so if you'd like to connect with particular project, let
me know and I can go ask them.
I'll be on #scons IRC and probably #buildbot
-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
--
_______________________________________________
Scons-dev mailing list
[email protected]
http://two.pairlist.net/mailman/listinfo/scons-dev
