my little tooth on cmake

[Kurt Pfeifle]

On Friday 17 March 2006 14:54, Cristian Tibirna wrote:
> 
> (NOTE: I already had to use cmake to compile VTK for many years already, so my 
> comment comes more from that experience).
> 
> Hello
> 
> My only with cmake is that it errects yet another level of indirection in 
> front of the new (or not so new) developer that wants to have a take on KDE-4 
> development. I.e., you have to actually _compile_ cmake (successfully! 

What for me does *not* compile right now for me, in 99% of cases, is 
kdelibs/trunk and kdelibs4_snapshot.

*cmake* itself did compile for me in the last 4 weeks daily, several 
times a day, successfully. The one time it didnt't, the reason was 
fixed within hours by the cmake developers after I reported it.

> and  
> the right version! 

The right version in this case is HEAD from their CVS.

(They recommend a certain release; and they did some inofficial "KDE 
releases" of tarballs which were known to work -- so there is no need 
to use HEAD even. It's just what I happen to do...)

I expect cmake's KDE support to be rather stable within a few weeks 
from now (at most 3 months), given that Alex started to work on cmake
support for KDE4 only a few weeks ago, initiall mostly on his own.

BTW, we even "ship" a "qt-copy" module via our SVN to be used for KDE
development. And we do the same for unsermake. So though I do not 
expect it to necessary, it is still an option to provide "cmake-copy"
by the same means.

> which is now a rather fast moving target) 

Most of the cmake "moves" happening are for the purpose of makeing
KDE build support more perfect. I think this movement will slow down
after things have settled a bit more in the near future.

> before even   
> coming close to compile KDE.

I do think that it is less a cmake problem when KDE4 does not compile
right now, and more a KDE4 problem. Or does KDE4 compile with autoconf
or unsermake or scons or bksys right now?

> I find it a very good thing that we move away from auto* (these always scared 
> me white) but we will need to put our collective heads into an acceptable 
> solution for this level of indirection problem. Precompiled binaries for most 
> common platforms, copy in our cvs... _I_ don't know, but _we_ will have to.

I didnt fully get what you hinted at in your last paragraph? Was it 
you want to offer precompiled *cmake* binaries for the most common 
platforms? (If so, and if something like that would *reallly* be 
needed, it could be sufficiently covered by a "cmake-copy" module
in our source-SVN, along the lines of "qt-copy"....)

> Thanks.

Cheers,
Kurt