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
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
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
(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
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,
(a Python-based build tool) was favored, spiced up with a KDE-wrapper called
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
would be the build system for KDE 4.
Beginning now, CMake will be the tool that is used to base all of KDE4 development.
including a section on the move of the Scribus project to CMake,
and the current state of KDE 4.
to post comments)