bksys / scons (Re: win32 port)

[Matt Rogers]

On Sunday 08 January 2006 02:07, Ralf Habacker wrote:
> 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
>

I've just subscribed to the scons list, and so i'd be happy to act as the 
liason between KDE and scons. 
-- 
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20060108/2135ca9f/attachment.pgp