ANNOUNCE: experimental support for building kdelibs 4 with cmake

Alexander Neundorf neundorf at
Sun Jan 15 18:59:58 CET 2006


maybe you have noticed, I have added CMakeLists.txt to trunk/kdelibs/.
With these files kdelibs/ can be built using cmake ( (not 

After some discussion on kde-buildsystem at this week
( )

in which I was encouraged to try to build kdelibs using cmake, I started 
working on this task.

We have also the support from the cmake developers, both Brad King and Bill 
Hoffman subscribed to the kde-buildsystem mailing list: .

cmake is an open source software build system, designed to replace autotools 
and with a special emphasis on portability. Currently it is developed by 
employees of Kitware Inc., they use it to build there own cross-platform 
software products (mainly ITK and VTK, see, so the 
situation is not that much different to Qt and Trolltech. cmake supports 
different buildsystems: makefiles (GNU, BSD, MS, Borland) and project files 
for MSVC 6,7,8, XCode 2 and KDevelop3. Among others it handles automatically 
the dependencies of libraries and executables which link to them in one 
project (i.e. kdelibs). 

Here you can find more information about cmake:


1) get cmake from cmake cvs and install it:
$ cvs -d :pserver:anonymous at login
(respond with password cmake) 
Follow this command by checking out the source code:
$ cvs -d :pserver:anonymous at co CMake
(as usual: configure, make, make install)

2) check out trunk/KDE/kdesdk/cmake
This directory contains the cmake scripts (in cmake language: "modules") 
needed to compile KDE using cmake. Installation is still manual: copy the 
files you find in kde3/, kde4/ and modules/ all directly into the system 
cmake module directory (usually /usr/local/share/CMake/Modules/ ), not into 
subdirectories !

3) Run cmake for kdelibs:

$ cd src/KDE/kdelibs/
if you want to use kdevelop:
$ cmake . -GKDevelop3
if you want to use XCode:
$ cmake . -GXcode (use the cmake help if the name of the generator is slightly 
if you want to use Makefiles:
$ cmake . 
if you want to use MSVC: run CMakeSetup

Then cmake will run and execute a host of configure checks.
If this succeeds, you will then be able to build kdelibs/, so either start 
make, or XCode, etc.
Currently nothing will be built, because it is commented out in 
kdelibs/CMakeLists.txt, I wanted to get the configure checks complete first.
In theory the configure checks should work on all platforms supported by 
cmake, i.e. linux, BSD, any UNIX, Mac OS X, Windows. But practically I guess 
the checks will have to be tuned a bit to work especially on Windows.

The current state:

All the CMakeLists.txt committed to kdelibs/ have been autogenerated with 

$ cd src/KDE/kdelibs
$ am2cmake --kde4   (the "--kde4" parameter is important !)

This script handles:
-creation of executables
-creation of shared libraries
-creation of plugins
-install rules for most filetypes
-adding most/some include directories as specified in
-adding most/some libraries to link to as specified in
-the --enable-final option
-the conditional build of test executables
-creation of a rule for doxygen
-creation of install rules for icons
-rules for ui, ui3, ui4, moc, kcfg, dcop stubs and skel

Issues/problems/open questions:

Most install rules specify the target directory using a variable, except the 
install rules for executables, libraries and plugins. There the install path 
is given directly relative to the installation prefix, i.e. "/bin" for 
executables, "/lib" for libraries and "/lib/kde3" for plugins. Are variables 
required for this ? I mean, there is a variable for the installation 
directory, and is it nevertheless required to have these three install 
location in variables ?

It doesn't convert custom rules found in's, so these have to be 
added manually.

It doesn't recognize various variables used in's, e.g. variables 
for include directories of software packages and other things like this, so 
this has to be adjusted manually.

It doesn't recognize conditions in the's, so these have to be 
added manually.

I haven't implemented support for meinproc yet. How do these rules look like ?

Having multiple targets with the same name in one project is not possible with 
cmake, e.g. and kdevelop have both the target name "kdevelop" 
in cmake. As workaround the executable kdevelop has to become the target 
"kdevelop_executable" (or something like this) and the property "OUTPUT_NAME" 
of this target has to be set to "kdevelop". Then it will produce both a and a executable kdevelop.

The install commands in cmake are not very powerful yet. The cmake developers 
know this and plan to improve them.

The build commands are all prefixed with "kde4". There is a cmake module for 
KDE 3 (FindKDE3.cmake) and one for KDE 4 (FindKDE4.cmake). Currently the 
commands in FindKDE3.cmake are prefixed with "kde3" and the commands in 
FindKDE4.cmake are prefixed with "kde4". This makes it obvious for which 
version of KDE they can be used, and it would be possible to build KDE 3 and 
KDE 4 (and KDE 5, 6 etc.) software within one project. 
OTOH it means "search and replace" if the major version number increases. I 
would prefer the kde3/kde4 prefixes, but I don't have a strong opinion on 
What do you prefer ?

The syntax for listing source files is different than in
xxx_SOURCES = main.cpp interface.cpp widget.ui config.kcfg interface.skel

in cmake:

set(xxxSources main.cpp interface.cpp)
kde4_add_ui_files(xxxSources widget.ui)
kde4_add_kcfg_files(xxxSources config.kcfg)
kde4_add_dcop_skels(xxxSources interface.h)

My main reason for not mixing them all together is the handling of the dcop 
stubs and skeletons. For me it was very confusing that with "interface.skel" 
a filename was given in the list of source which doesn't exist and which will 
never be created during the build. IMO this is hard to understand: "well, if 
you want to build dcop skeletons, make up a hypthetical filename acccording 
to this and that rule, and add it to the list of sources, then the 
buildsystem will magically guess what you meant by it and do something."

IMO although it is more typing

kde4_add_dcop_skels(xxxSources interface.h)

it is very obvious and IMO for the average programmer (at least for me) it is 
easier to follow what will happen, since I see a concrete function name 
("kde4_add_dcop_skels()") in this line. With this function name I can search 
for this function in the cmake modules to see/improve/debug its 
implementation. I think this avoides the "Convenience Trap" as Matthias put 
it (
If we don't find a better way than to make up non-existent filenames for the 
dcop stuff, I really think this way with the explicit function calls for each 
type of files is the better option.

So, I hope I didn't forget too many things and you are all informed now.
Please have a look at the created files and let's discuss the "API", 
preferrably on kde-buildsystem at

Work: alexander.neundorf AT -
Home: neundorf AT                -
      alex AT               -

More information about the Kde-buildsystem mailing list