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" <[email protected]> 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: [email protected] [mailto:[email protected]] 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 <[email protected]> > wrote: > On Tue, Mar 19, 2013 at 9:59 PM, William Deegan <[email protected]> > 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 > [email protected] > http://two.pairlist.net/mailman/listinfo/scons-dev
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
