[Scons-dev] Schedule for redesign?

[William Deegan]

Dirk,

On Oct 27, 2013, at 3:02 AM, Dirk Bächle <tshortik at gmx.de> wrote:


> Hi,

> 

> over the last few days I had another look at SCons' speed and memory problems. As posted in an earlier email, I am able to reduce the maximum amount of memory used during runtime (both, clean and update builds) by up to 50% in large C/CPP projects.

> This is reached by freeing infos in the Node class itself, when they aren't needed anymore after a target is built/visited.

> 

> Having identified a set of Node attributes like this, somewhat lends itself to refactoring them out into its own class (TargetInfo?). There has always been some rumor about a redesign of the Node classes and the Taskmaster, which is what this is pretty much about...although not in a very broad range.

> 

> What I'd like to do (and actually already started in a private branch) is to refactor a few classes and imports, like follows:

> 

>  - move the GetOption/SetOption/FakeOptionParser stuff out of SCons.Script.Main into SCons.Options (have this ready)

>  - move the Task classes (Clean/AlwaysBuild/...) out of the SCons.Taskmaster into their own module SCons.Tasks (ready, too)

>  - move the Node attributes mentioned above into their own class SCons.TargetInfo (tbd)

> 

> In effect, funtionality gets shifted to where it belongs conceptually, and not where it is "needed". This might make access to certain parts a little more complicated, in the sense that one more often needs to delegate things or distribute information like option flags to several places. But it also makes the design overall easier to grasp and explain...at least in my opinion.

> 

> Now my question (see the title): When would this fit into our current development schedule? Should I just go ahead and propose one (or several) pull requests, or wait until the Python 2to3 conversion is over and things have settled. Do you think we need a special deprecation cycle for this, or maybe even should switch the version number to 3.x then?

> 

> Your comments are welcome…


My two cents..

Smaller pull requests sound good.
I don't think we need any deprecation if it's an internal API.
Those have never had any promise of being stable.
Though you might want to point out the pull requests specifically to Jason Kenny to see if it's going to throw a wrench into his Parts extension.

I don't see any reason to wait until 2to3 is completed.
Though it might be work 2to3'ing your new/changed code to see if there is any simple changes which might resolve some issues.
So in other words, try not to add additional difficulties in getting code ready for python3.

Thanks for your efforts!
-Bill