[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