[Scons-dev] GSOC this year?

[Gary Oberbrunner]

I really wish I could but this summer is going to be a lot of work for me
already.  I can be your backup though, Bill.


On Tue, Mar 26, 2013 at 5:05 PM, William Deegan
<bill at baddogconsulting.com>wrote:


> 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

>

>

>

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

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

>

>



-- 
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20130327/24e4b714/attachment.html>