bksys / scons (Re: win32 port)

[Jaison Lee]

> > 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'm willing to take Thomas's word that the scons folks will be
unresponsive to changes to scons. He gives the impression of someone
that has already been down that road. :)  Just looking at the scons
project from the outside makes me think that.

That said, scons as it is is gaining acceptance and I just hate to see
KDE keep its own fork of scons unless it is absolutely necessary. KDE
is a big enough project as it is. I would view a local scons fork as a
drain on developer time unless there are some EXTREMELY motivating
reasons, and I'm not sure that the things Nagy has said so far has
convinced me it's necessary.

Unsermake for example fixed some very serious problems in make that
could cause it to fail to do what it was supposed to do. I'm not sure
that a difference in command line options and a moderate speed gain
are worth it for scons. The most damning thing against scons is its
adherence to Python 1.5, but I still don't see why that would bother
us. There's no reason that bksys has to support Python 1.5.

(I'm new to the build system community, so if I'm alone in my thinking
or speaking out of turn then let me know and I'll shut up
immediately.)



On 1/7/06, Nagy Thomas <tnagy256 at yahoo.fr> wrote:
> > > 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
>

>
>
> Regards,
> Thomas
>
>
> /* Thomas Nagy */
>
>
>
>
>
>
> ___________________________________________________________________________
> Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
> Téléchargez sur http://fr.messenger.yahoo.com
> _______________________________________________
> Kde-buildsystem mailing list
> Kde-buildsystem at kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem
>