bksys / scons (Re: win32 port)

[Matt Rogers]

On Mon, Jan 09, 2006 at 07:04:07PM +0100, Albert Astals Cid wrote:
> A Dilluns 09 Gener 2006 18:33, Jaison Lee va escriure:
> > I hate to add fuel to a conversation that has no doubt gone back and
> > forth already, but what *was* the primary reason that scons was
> > chosen?  As a newcomer looking things over I have been baffled at how
> > bksys is using scons. Most everyone here seems to think that the main
> > scons tree has intolerable problems, and there are so many layers
> > (especially once the "SConfigure" system gets made) that it barely
> > resembles what a normal scons build system looks like.
> >
> > Don't get me wrong; I use scons at work and I really like it, but if
> > it isn't capable of handling KDE then why are we trying to make it do
> > so? Is it really worth keeping a KDE specific build system (which is
> > what we are moving towards)?
> >
> > scons/bksys has been in development for months and yet it seems to be
> > months away at best from even being serviceable. Perhaps it's time to
> > cut our losses and run.
> 
> I *could* agree here, iirc scons was choosen because:
> a) we wanted something to replace auto*
> b) we did not want to create a Kde-only solution 
> 
> We are falling into the b) situation now, so we maybe should reevaluate 
> things.
> 
> Albert
> 

I don't understand why everybody has gotten wishy washy all of the
sudden. How much work went into our autotools build system? I'd wager
quite a lot. How many people were working on it at the time? I'd guess
maybe 6 over the years. Build systems are complicated things. I get the
feeling that people just expect things to drop out of a hat and just
start working and that's not the way it works at all.

I firmly believe that SCons is capable of handling KDE, just like I
believe that CMake is capable of handling KDE. please keep in mind that
this time around, building KDE is harder with a new system because
(unlike during the age of autotools) KDE is now huge, and rather than
doing things step by step wrt adding special things like support for
dcop files or kdeinit module when those ideas came about, it all has to
be done at once and that takes time. Let's also not forget that we're
dealing with the most complicated module in terms of the build system
with kdelibs and that helps contribute a bit to the "scons isn't
working" impression.

I'd suggest a little patience, and if there's something that we need
from scons then we need to bring it up on this list so that i can go to
the scons development team and say, "hey, we're using scons, and we'd like it
to do X, Y, and Z." and get support from them. If you've read the scons
dev list archives, they know we're using scons for KDE, and they've
offered support if we need it. we should take advantage of that.

If after some more time, scons still isn't working for us, then we
switch. From my POV, we're still in the evaluation stage.
--
Matt