[Scons-dev] Schedule for redesign?

[Dirk Bächle]

Hi Jason,

and thanks for chiming in.

On 28.10.2013 17:07, Kenny, Jason L wrote:

> I hope I would not be a wrench in engine :-)

>

> Honestly The issue that this is work and I have to do this at home is the main reason I have not pushed anything at this point. ( And having twin 3 years-old means I don't have the go power at the end of the day...)

>

> I would agree with what is being stated. I would go a bit farther however.


I understand that you have done some work on redesigning/refactoring 
parts of SCons, and you certainly don't want to lose it for nothing. So, 
I'd like to make the following suggestion: I'll factor out some 
attributes of the Node class into their own module and commit these 
changes (together with the other rewritings I mentioned) to a named 
branch in my personal "experimental" SCons fork.
Then you can have a look at it and check whether you'd be able to base 
your further work on that. If not, you can tell me what should be 
changed such that you can continue properly with your work. If I get 
your "okay", the changes find their way into the SCons core and you can 
take it from there whenever you find the time. How does that sound?


> I would redesign the Node API. But also redo the executioner logic. Ideally we want I have learned is that the task logic needs to be updated. Greg Noel was on the correct path with TNG in that we want to execute "builders" not nodes. We also need the API ( internal) to decouple the relationships with the tasks and the nodes.

>

> I would also look at fixing up the subst engine. I found that this is another area of memory waste at the moment ( and not in the good way). This might be more of an issue with Parts as I currently use the subst engine to share data between different "parts"/ components. Until I do a new part file format and or a "continuous loader" I have no way to pass data correctly.


During my investigations I tried to speedup subst() by caching some 
pre-expanded strings, but it didn't work out. My current impression is 
that you either have to compile it (including optimizations by hand, 
simply running Cython over it is not enough!) or reduce functionality 
(like cutting down the support for callables) to get it faster.

But don't let me stop you from trying... ;)

Best regards,

Dirk