[Scons-dev] GSOC this year?

[William Deegan]

All,

Time's running short if we want to do this.

I'm willing to be a mentor,is anyone else available to do so?

_Bill

On Mar 20, 2013, at 8:54 AM, "Kenny, Jason L" <jason.l.kenny at intel.com> wrote:


> 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> wrote:

> On Tue, Mar 19, 2013 at 9:59 PM, William Deegan <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

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

> http://two.pairlist.net/mailman/listinfo/scons-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20130326/35f3397f/attachment.htm>