bksys / scons (Re: win32 port)

[Ralf Habacker]

Matt Rogers schrieb:

>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.
>  
>
I think this too:
As above said, creating a new build system is a major task and from my 
perspective there are currently some unix build system and python 
experienced people missing.

There are other parts of the buildsystem where many people had 
contributed very good code. I remember the amview tool and the am2bksys 
converter the configuration checks on windows and linux and better qt4 
and KDE4 detection support, so I am very happy to see what is reached.

But now we are coming on a limit, where the currently used project 
management isn't able to break down the limit. Let me tell some examples:

I had implemented an initial dep file suppport, but recognized that I'm 
not able to implement the unix relating stuff, which is much more 
complicated as under windows. If I would implement this part for linux, 
this would be probably lost work.:-(

Relating to the configuration stuff I collected ideas about the modular 
configuration stuff and made a proposal 
(http://webdev.cegit.de/snapshots/kde-windows/bksys/doc/html/config_custom.html. 

I released this to give other an overview and to get reviewing. 
Additional an initial parser of SConfigure files was releases 
(bksys/configure.py)  But unfortunally noone felt able enough to work on 
or comment this part too. :-(

Then I takes a deeper look into the scons configure stuff and saw, that 
there are currently two partially different implementations, which makes 
it very hard and unsure to extend, because it wasn't known which 
implementation will be the only one in the future.

Additional I contributed an important cygwin patch scons to the scons 
patch tracker 3 month ago, which wasn't accepted until now. Seems they 
don't like patches. Very uncomfortable situation.

Because of this I wrote about getting a good working together to the 
scons people, If scons should have a future as base of the KDE  
buildsystem.

Ralf