[Scons-dev] GSOC this year?

Kenny, Jason L jason.l.kenny at intel.com
Wed Mar 20 11:54:30 EDT 2013


As far as toolchain I think I made good inroads to this problem, I am not done, I can list a few items that need to be enhanced as of yet or finished with what I have done.

The main issue I think given some of your suggestion are that we need to some improved infra to support these idea. This stuff is not simple. The details can become a real issue.

Jason

From: scons-dev-bounces at scons.org [mailto:scons-dev-bounces at scons.org] On Behalf Of Gary Oberbrunner
Sent: Wednesday, March 20, 2013 10:38 AM
To: SCons developer list
Subject: Re: [Scons-dev] GSOC this year?


On Wed, Mar 20, 2013 at 10:34 AM, anatoly techtonik <techtonik at gmail.com<mailto:techtonik at gmail.com>> wrote:
On Tue, Mar 19, 2013 at 9:59 PM, William Deegan <bill at baddogconsulting.com<mailto:bill at baddogconsulting.com>> wrote:
Folks,

Anyone interested in mentoring for GSOC for SCons this year?
Any appropriate projects ?

Build SCons diagrams, and tools, yes. Research current, define and implement next mechanisms for:
1. Tool discovery
2. Tool initialization
3. Dependency graph construction

Thanks for this, Anatoly. I agree with much of what you suggest as good projects for SCons. We can quibble about whether some of them are appropriate size for a summer student (having mentored a few GSoC kids, I have a pretty good idea how far they can get), but the other question is whether anyone here has time to mentor them. I really really wish I did -- I did it three years running and found it great. But I don't have time this year.

If we can find mentors, then let's go for it.

That said, I think toolchain revamp is probably too big for a summer student; if we were a bit further along, porting existing tools to a new framework would be about right. But we're not there yet. I like your visualization ideas though, and to those I would add a bunch of Python3/2.7 porting work.


-- Gary

With the goals:
1. Initialize only tools that are necessary for the target
2. Toolchain management and control
2.1 Configure toolchains
2.2 Select toolchains and their components
2.3 Dynamically construct toolchains based on different parameters (availability, input/output compatibility)
This will require some research, maybe even cyclic process, because there is catch22:
- graph is needed to define which tool are required
- graph is constructed using methods provided by those tools
(I suspect that Parts project is somehow related and Jason can add details here)

Visualize SCons internals:
1. Define phases of execution
2. Show phases in a visual interface
3. Hightlight phases in realtime as they pass
---
4. Draw dependency and execution order graph
5. Highligh graph in realtim as the targets are build
---
6. Implement stepped execution
7. Implement delayed execution

OS-independent asynchronous subprocess implementation:
https://bitbucket.org/techtonik/absub
1. Visualization of the algorithm
2. Tie Visualization to the realtime SCons process
3. Fix to make it work with SCons

Declarative format for certain tasks (such as compiling C libraries). This will make SCons interchangeable with other tools like CMake for simple tasks, will allow project members to use tools of their liking, and enable us to concentrate on higher level differences and usability scenarios.


--
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20130320/0b602356/attachment.htm>


More information about the Scons-dev mailing list