bksys / scons (Re: win32 port)

[Ralf Habacker]

Nagy Thomas schrieb:

>>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).
>  
>
It is usable on windows mingw too with only minor problems.

>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
>
may be for unix based os. For windows os there is currently no choice.

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