Why the KDE project switched to CMake -- and how [LWN.net]

June 19, 2006

This article was contributed by Alexander Neundorf

Why the project revamped its build system for KDE4

KDE developer Alexander Neundorf explains the background for the move away from the traditional "autotools"

KDE is one of the largest Free and Open Source Software (FOSS) projects. It follows the typical "distributed development" model used by many other FOSS applications. More than 1.200 developers around the planet have accounts and credentials to access its central source code repository. This repository currently holds more than 4 million lines of program code, translations of approximately 100,000 user interface strings (and many more lines of application manuals) into more than 80 different languages. Every day there are about 300 or more "commits", adding new or modifying existing content.

Any software project of this size and scope can only prosper and go forward if it uses tools that are good enough to manage and build all its code, for all its contributors, on all supported OS and CPU platforms, all the time, without major problems. Oftentimes "good enough" here translates into: "the best one that is available for our purposes".

For its central source code management KDE last year migrated from the venerable "Concurrent Versioning System" (CVS) to the newer, more powerful Subversion (SVN) software. That change in itself was an enormous stress test for the capabilities of the still young SVN project: a year ago, several preparatory "dry runs" which simulated the pending move revealed quite a number of bugs and performance problems in advance. Close cooperation of some core KDE hackers with the Subversion developers lead to fixes and improvements to SVN itself before the real change-over for the huge KDE repository finally happened.

Now the next big change is happening: KDE is leaving the aging "autotool" build chain behind. Some developers, not only in KDE, like to nickname the autotools as "auto-hell" because of its difficult to comprehend architecture. So, KDE 4 will feature a completely different build system: CMake.

In typical KDE fashion the current move to CMake was not a "decision by committee". Instead, the old rule "who codes, decides" made itself felt once again. Let's look back at the history of this change.

The principal move away from autoconf, automake, configure, libtool & friends was decided at last year's annual KDE conference, akademy. KDE developers at the time discussed and evaluated several alternatives: back then, SCons (a Python-based build tool) was favored, spiced up with a KDE-wrapper called bksys to help with the actual work. SCons/bksys already worked well for a number of developers who used it in their sub-projects, and the tandem seemed to easily win the race. Up until January 2006, several people worked hard on replacing the existing autotools based build system of KDE3 with SCons/bksys for KDE4. Their first acid test was to make it compile kdelibs on various platforms.

However, various hurdles showed up unexpectedly. The KDE individuals who tried to bring SCons into a shape that made it fit for building such a huge project felt they didn't have any support from the upstream SCons developers. There were major problems building KDE on non-Linux platforms with SCons (e.g. on OS X); in general they felt it did not yet have a mature configuration system. The only option down that road was to create major SCons fixes and patches on their own. Since these changes would not likely be included in the upstream sources, it would require permanent maintenance of the fixes in a separate repository. In effect, this would have amounted to a fork of SCons. KDE developers would have had to maintain the new build system entirely on their own. So the rosy SCons/bksys image paled again....

It was decided that CMake would be the build system for KDE 4. Beginning now, CMake will be the tool that is used to base all of KDE4 development.

Read the Full Article, including a section on the move of the Scribus project to CMake, and the current state of KDE 4.

(Log in to post comments)

Why the KDE project switched to CMake -- and how

Posted Jun 23, 2006 10:00 UTC (Fri) by neiljerram (subscriber, #12005) [Link]

As far as I can tell from the CMake web pages, CMake doesn't appear to cover two big areas that are covered by autoconf/automake/libtool, namely:

(1) checking for availability of particular headers, functions, libraries, or OS-dependent behaviour of existing functions (and adjusting defines and flags accordingly)

(2) knowing how to build and link shared libraries correctly on all the Unix-like OSs.

In other words, CMake is an alternative automake (whose notable extra feature is that it can generate MSVC project files as well as Unix makefiles), not an alternative autoconf/automake/libtool.

Is that correct, or have I misunderstood?

- Neil

Why the KDE project switched to CMake -- and how

Posted Jun 23, 2006 10:38 UTC (Fri) by aleXXX (subscriber, #2742) [Link]

It covers both of them.
It can build and link shared libs on all Unix-like OSs. What did make you
think it can't ?

It supports full system introspection using the FIND_PATH(),
FIND_PROGRAM(), FIND_LIBRARY(), CHECK_FUNCTION_EXISTS(),
CHECK_HEADER_EXISTS() etc. functions. They are used e.g. extensively for
KDE4 on Linux, FreeBSD, Mac OS X and Windows (mingw and MSVC).

Check the cmake man page and the Wiki:
http://www.cmake.org/Wiki/CMake_HowToDoPlatformChecks
http://www.cmake.org/Wiki/CMake_HowToFindInstalledSoftware

Alex

Why the KDE project switched to CMake -- and how

Posted Jun 23, 2006 13:16 UTC (Fri) by neiljerram (subscriber, #12005) [Link]

Thanks. I spent some time looking at the docs, FAQ and examples that are linked from the CMake home page, but didn't see anything alluding to these issues.

I'll take another look, including the specific pages that you mentioned.

- Neil