[cmake-developers] akademy summary

Alexander Neundorf neundorf at kde.org
Sat Sep 30 09:40:04 EDT 2006


Hi CMake developers,

so yesterday I came back from aKademy, the annual KDE contributors meeting and 
conference (http://static.kdenews.org/jr/akademy-2006-group-photo.html).
As you know, CMake is the buildsystem for KDE4.

First of all, you can be proud that the akademy award for the best 
non-application contribution to KDE was given to "CMake for KDE4" (i.e. me). 
But that means in general that the people really like the change from 
autotools to CMake.

Some of the comments:
Adam Treat, KDevelop developer: "CMake is a god's end compared to what we had 
with autotools."
Martin Konold after Bill's talk, who initially set up the KDE cvs server back 
then, KDE e.V. member, KDE Qt Free Foundation, http://www.erfrakon.de: "The 
talk was very interesting. Kitware seems to be a very focussed small company, 
which gets things done. I didn't know that gcc_xml is also done by Kitware."
Several other developers expressed that they like CMake, among them Adrian 
Schroeter, project lead at SUSE, Tobias Koenig (KDE Pim), Holger Schroeder 
(KDE on Windows) and several others, can't remember them all.
Somebody expected a more cmake-howto-like talk from Bill, but when they heard 
that that's what I do in the CMake BoF it was ok for them.
Somebody emphasised how KDevelop was mentioned in one go with MSVC and 
XCode :-)

There were also some wishes:

1) make the cmake run faster

20 to 25 % of the cmake time in KDE is spent on the automoc macro I wrote, I 
will move this to buildtime, this will help quite a bit

Tobias Koenig had the idea to create a binary cache for the parsed cmake 
files, and only parse these files again which have changed. I'll have to 
check how much time is spent for the parsing alone.

2) make the dependency checking faster

hard to do

3) provide a target to build the tests, and don't build the test binaries by 
default without having to adjust a cmake option

I'll have a look whether this is possible with the current feature set of 
CMake, I already talked with Bill about it.

4) configure-style options

The -DSOMEVAR:TYPE=value requires a lot of typing, so being able to say "cmake 
<dir> --prefix=/opt/kde" would be nice. I have an almost finished patch for 
this on my harddisk.

There were no serious problems mentioned, there still was some nitpicking 
about the if(cond) endif(cond) syntax, but nothing serious.

People are starting to use CMake also for their non-KDE-subversion projects.
Several people committed patches, Tobias Hunger wrote a "gencmake" script 
( http://websvn.kde.org/trunk/KDE/kdesdk/cmake/scripts/ ) which creates 
simple cmake files from just looking at the files which exist in a directory 
(qmake does something similar), Holger Freytag added an additional buildtype 
for profiling, Jakob Petsovits (KDevelop) added a FindFlex.cmake module, QCA 
(Qt Crypto Architecture) can now be compiled with CMake and more.

We had a KDevelop BoF where we discussed the CMake <-> KDevelop integration, 
I'll write an extra mail about this.

So, all in all, in general the KDE developers like CMake, if some things could 
be made even faster, there would be almost no complaints left.

Beside all that, it was a really nice event, I'm very happy that I had the 
chance to meet Bill in person, and the other nights we spent in Dublin's pubs 
and consumed larger amounts of Guiness and friends :-)

Bye
Alex
-- 
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org                - http://www.kde.org
      alex AT neundorf.net               - http://www.neundorf.net



More information about the cmake-developers mailing list