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

[Dot Stories]

URL: http://dot.kde.org/1172083974/

From: Troy Unrau <troy.unrau at gmail.com>
Dept: now-with-even-more-exciting-compiler-scroll
Date: Wednesday 21/Feb/2007, @10:52

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 [http://cmake.org/], 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 [http://www.kitware.com/] and
a team of open source developers. It is released under a BSD-style
license [http://cmake.org/HTML/Copyright.html]. 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 [http://www.kdevelop.org/] 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
      [http://lists.kde.org/?l=kde-core-devel&m=113734805302055&w=2],
      now just over one year old.
    * An earlier article on KDE + CMake
      [https://lwn.net/Articles/188693/] published at Linux Weekly News
    * KDE + CMake beginners guide
      [http://wiki.kde.org/tiki-index.php?page=KDECMakeIntro], courtesy
      of the KDE wiki.

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