bksys / scons (Re: win32 port)

[Ralf Habacker]

Nagy Thomas schrieb:

>>>I did, and our requirements (like 'a good
>>>configuration framework') are wanted by many other
>>>people too. Scons is throttled by backward
>>>compatibility, and its (now very low) amount of
>>>developers with commit access.
>>>
>>>      
>>>
>>Perhaps we could convince them that breaking
>>backwards compatibility is 
>>perhaps the only way to move their project forward?
>>    
>>
>
>Try and see.
>  
>
>>Even the oldest of 
>>distributions should have python 2.2 and there is a
>>windows version of it. Do 
>>we know why they insist on keeping backwards
>>compatibility with python 1.5.2?
>>    
>>
>
>Several companies are relying on scons for in-house
>development, as a result not-so-useful features cannot
>be changed or removed. But you should probably ask
>them yourself.
>
>  
>
>>do you know where the performance problems are?
>>    
>>
>
>Too much string manipulation (substitution parsers
>using regexps), discutable design decisions (like
>rescanning everything everytime), little code
>flexibility.
>
>  
>
>>>* the source code of scons must be kept compatable
>>>      
>>>
>>to
>>    
>>
>>>python 1.5.2
>>>      
>>>
>>why is this an issue?
>>    
>>
>
>Python 1.5.2 is too old, as a result, many features
>found in Python 2.2 have to be reimplemented just for
>scons.
>
>  
>
>>>* command-line handling is not compatible with
>>>autotools and difficult to fix
>>>      
>>>
>>why does it need to be compatible? scons != automake
>>    
>>
>
>I was asked for this:
> scons --option=35 -t
>as the following is not satisfactory:
> scons option=35 t=True
>
>  
>
>>IMHO, the best solution is to fix scons. Then we're
>>not the only ones who gain 
>>from the fixes, because if we're having these
>>problems, then others are bound 
>>to have them as well.
>>    
>>
>
>I agree, just make patches and have them accepted
>first. I have started some experiments that i have to
>finish now.
>
>  
>
I think the most important point is to get in a working relation with 
the scons developers/maintainers. Is someone of the developers listed on 
http://sourceforge.net/project/memberlist.php?group_id=30337 known to 
anybody, so the he can contacted directly ? Or can some KDE e.V  
representives make an official request for a "how to work together" and 
"how to extend/optimize scons in area .... without breaking other stuff 
too much or giving an migration path"- or similar meeting with the scons 
people ?

 From the scons development page (http://www.scons.org/dev.php)

" ScCons design documents 
<http://sc-archive.codesourcery.com/entries/build/ScCons/ScCons.html>
The original design, from the Software Carpentry 
<http://software-carpentry.codesourcery.com/> build tool contest, on 
which SCons itself was based. This is now of more interest as an 
historical document, since the current design has changed significantly 
as we figured out how to make things easier."

Why should the recent design should not be changed  when ther are ways 
to make it more easier or faster ?

To take the scons configure stuff as example, it should be possible to 
take the two or three related python files, make an extended design in 
coordination with the scons people and implement this (if someone is 
willing to learn how scons is implemented and have the time or is 
sponsered by someone else). Sure, it costs time (and money if done in 
worktime) and there will probably only very few people know scons 
internal very well (I hope at least two). But all this will not be 
possible, if we cannot came in good contact with the scons people.

Ralf