bksys / scons (Re: win32 port)

[Nagy Thomas]

> 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.

To help your re-evaluation:
* Scons is the engine that is used to find the
dependencies and launch the commands to build targets
from sources. It does have some technical problems
which make a refactoring necessary, and these somehow
require some changes that means rewriting some parts
of it (or few big patches).
* Bksys is a thin layer on top of scons to declare the
targets in an object-oriented way similar to the
makefile.am syntax (which is said to be the most
intuitive one), and to make the configuration.
* The few scripts in bksys are re-usuable for about
anything in fact - and it took quite some time to
understand what developers actually wanted
(configuration). The scripts are not particularly tied
to KDE as bksys was used to build wx or gtk apps in
the past.

What i am doing at the moment is to refactor Scons
(ok, with an ax) to make it do exactly what we need to
and more (faster than unsermake, and as small as
possible are my goals). The issues with scons are
tolerable, but it would be ideal if they were fixed,
and i am heading to this point (snapshot at
http://freehackers.org/~tnagy/waf-0.5.5.tar.bz2).

And concerning the part "scons/bksys has been in
development for months and yet it seems to be months
away at best from even being serviceable", all i can
say is that the previous version for kde3 was
serviceable (kdissert).

You might want to switch to cmake that Alex is
advertising now and then, though issues encountered
for the configuration and the compilation will be 
very similar, if worse. The best i can say is that you
should probably stick to unsermake for KDE4 until any
replacement is ready (it is in python, perhaps things
may be exchanged with bksys). For now i am committed
to my work on bksys and on the scons engine.


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