The Road to KDE 4: CMake, a New Build System for KDE

When a project with the size and scope of KDE gets to be as big as it is, sometimes changing a decision established almost a decade earlier is very difficult. KDE has relied on autotools to build most of the project since its inception, but for the last year, KDE 4 has been building with CMake, a newer build system that is rapidly becoming a heavyweight contender in the world of buildsystems. Read on for more...

This article focuses on CMake, which is not actually part of KDE, but is developed independently by Kitware and a team of open source developers. It is released under a BSD-style license. I can't really show much in the way of screenshots for a build system, but I will do my best to explain why CMake has been a welcome change to the KDE development process.

But before we talk about CMake, a little history lesson about KDE and autotools. KDE has used Qt since the beginning, and one of the nice features of Qt is the meta-object compiler (moc). Autotools had to be extended to support using moc as a pre-processor for most of KDE's header files. That was only the beginning though, as KDE developers wrote the ground-breaking DCOP communication protocol which also had the side effect of adding more types of files that had to be autogenerated during the build process. The developers added document compilers, tools that automatically handled translations, and tools that compiled configuration file classes from XML: Qt's User Interface compiler (for .ui files) was born and needed to be supported by the build system. They also needed to add a whole suite of new configure checks, options, etc. to support all of the features that KDE was using. The KDE build system was evolving into a very complex animal, and using autotools did not scale well.

By the KDE 3 series, there were only a select handful of elite build gurus who could understand the whole of KDE's build system. KDE developers had trouble even moving things from one folder to another without having to spend hours tweaking build files to get it to compile again. And in some cases, starting an independent KDE project meant shipping up to 500 KiB of autotools support files for even a simple 'hello world' type application.

Something obviously had to be done for KDE 4 to improve this situation, and at an Akademy 2005 meeting, it was decided to explore other build system options. Initially, SCons was prototyped for building KDE, but it was slow going, and after several months of work it still did not handle kdelibs well enough to dump autotools. One of the bigger problems with SCons was its lack of modularity.

So, as is often the case with KDE, he who codes, decides: Alexander Neundorf stepped in and did the initial port to CMake which went very smoothly, and he did so with the support of the CMake developers. It took only a few weeks to get much of KDE building smoothly using CMake, and autotools was finally dumped!

The CMake developers have been very supportive of KDE's transition. They even joined KDE's buildsystem mailing list to help out. This relationship has been beneficial to both projects. When KDE started to really stress the capabilities of the still-maturing CMake system, KDE developers started a dialogue with them suggesting improvements - and they were happy for the feedback. As a result, CMake has seen improvements that are beneficial to all projects using the buildsystem.

Our working relationship aside, CMake has greatly improved the process of building KDE. Projects using CMake take less time to get started, since there is less time spent fighting with the build system. One KDE developer says, "CMake doesn't make you want to shoot yourself with a nailgun when building your project anymore."

The way CMake works is by processing an easy to read file called 'CMakeLists.txt' which the developer adds to their source folder. When you run the 'cmake' command, it looks for this file, and based on its contents, it generates Makefiles (on UNIX), or using a command-line switch it can generate XCode project files so you can build Mac applications using OS X's XCode developer tools, or using yet another command, it can even generate MSVC projects from your sources. One of the best KDE-related features of CMake is that it can automatically generate KDevelop project files based on the same 'CMakeLists.txt' used to generate the Makefiles.

KDE's code (with a few exceptions) was already pretty portable, however it was nearly impossible to build KDE on systems like Windows, where autotools was not as well suited. Now much of KDE's improved platform support is thanks to the ease of building on these systems (And of course, Qt being available as GPL on these systems).

In KDE 3.x, building KDE using the recommended methods looked something like this:

% ./configure --prefix=/foo --enable-debug
% make
# make install

As you can tell, this is pretty standard autotools-style building, except that the scripts which controlled the build process are pretty hard to understand.

With CMake, there are some syntax changes (which may actually be less obvious than the old, familiar configure switches), but the commands are mostly the same.

% cmake -DCMAKE_INSTALL_PREFIX=/foo \
    -DCMAKE_BUILD_TYPE=debugfull .
% make
# make install

This syntax does not look like a huge improvement, but looks can be deceiving.

CMake searches for dependencies several times faster than the './configure' process did. CMake builds KDE 4's kdelibs about 40% faster than autotools build KDE 3.5.6's kdelibs, mostly due to a lack of libtool in the toolchain for CMake. The CMake toolchain (for UNIX) looks something like: cmake + make, whereas the autotools chain for KDE 3.5.6 looked something like: automake + autoconf + libtool + make + sh + perl + m4.

I'm going to rely on some of my own personal experiences here to help explain how much easier CMake is to use: Aaron Seigo asked for some help to port some of kdesktop's components into krunner so that kdesktop could finally be killed off in the KDE 4 tree. This is the sort of task that I would not have attempted to tackle in the KDE 3.x tree, not because the code was any harder, but because the build system was so difficult to deal with. In all likelihood, I would not have volunteered for such a task for KDE 3, but with KDE 4 and CMake, after moving the code around and doing some class renaming and such, I smoothly inserted the ported code into the build system, modifying only two or three lines of krunner's CMake build files. It built after a few minutes, and linked and installed. I was so impressed that I've kept contributing porting help. In KDE 3, I probably would have been stumped by the build system (not the actual KDE code) and given up, not bothering to commit my code to KDE SVN.

This only goes to show that the build gurus of KDE can worry a lot less these days, as anyone can get their projects up and running. Your milage may vary, but many developers have expressed similar feelings when dealing with the 'CMakeLists.txt' syntax vs. 'autotools'. However, almost all of the KDE developers would now be considered CMake newbies. The CMake developers have been personally involved in ensuring that KDE's transition is as smooth as possible.

The switch to CMake isn't the first time KDE has changed one of the technologies central to its development. When KDE was younger, we used CVS to control access to the sources. Maintenance of the CVS server was not scaling well as KDE was growing, amassing enormous amounts of code dating back to its original commits. Subversion (SVN) offerred a promising new revision control system that was a better fit for what KDE needed to accomplish, and was easier on our servers. At the time, however, no project the size of KDE had migrated to SVN, and it was a real test for the Subversion software. But KDE and SVN have been a pretty good fit, and since KDE migrated, many other projects have since followed in its footsteps.

KDE's use of CMake has helped to raise the public profile of the buildsystem, much like how the switch to Subversion helped their profile. Other projects have been switching to CMake too, including (but not limited to): Scribus, Rosegarden (switched from SCons), PlPlot, ChickenScheme, and more. There is also work being done to support building KDE 3.x programs using CMake (KPilot for KDE 3 can build using CMake, for example). Projects looking for an easier way to build whilst adding support for more platforms should give CMake a try. Adding a 'CMakeLists.txt' file to your sources does not interfere with your project's existing build system and can give you a good overview of what CMake can do for you. And, like KDE, if there's something it cannot handle, the CMake team is very open to improvements.

Some links that may be useful for those interested in more information:

• The original post by Alex about the port to CMake, now just over one year old.
• An earlier article on KDE + CMake published at Linux Weekly News
• KDE + CMake beginners guide, courtesy of the KDE wiki.

I promise to have some eyecandy next week folks, until then...