At the build system BoF at aKademy it was decided to start moving the KDE 4 build system from unsermake to the SCons/Python based system bksys. To find out more about this important future technology, KDE Dot News talked to its lead developer Thomas Nagy about the reasons behind the change and what it will mean for KDE developers.
Thomas is ita on IRC
Please introduce yourself and your role in KDE.
My name is Thomas Nagy (I am also known as 'ita' on
freenode). I have spent some time writing some KDE
utilities (solvers, small games) and adding
some features to KDE applications such as KOffice and Kalzium
when i was still a student. Since i graduated i have
spent more time trying to create complete applications
like kdissert, a mind-mapping tool for the creation of
documents and its build system bksys.
What is SCons and what is bksys?
SCons is a software construction tool which is used to
build and install programs. It is written in Python
and its design is modular, making it easy to extend
for use with unsupported compilers or complicated
bksys (as in Build Kde SYStem) extends SCons and aims
at replacing the autotools. It has been written in the
main place for compiling and installing kdissert and
became more modular over the time. The most important
feature is the object-oriented style API that can be
accessed from either Python code or throughout XML
Some more documentation describing the framework can
be found in the the slides from my aKademy 2005 presentation.
Why is bksys separate from SCons?
bksys aims at replacing completely autotools for
common projects, so this goes way beyond SCons' main
In which way are they better than autotools?
There are many improvements over the autotools, but I
will try to describe the most striking ones:
- Reliability: targets are rebuilt if compilation
flags are changed or if md5sums of the files changed
- Size: 100KB (miniSCons included) vs 600KB
- Simplicity: one language (Python) versus at least 3
(m4, posix sh, make) for autotools (GNU/make,
automake, autoconf, libtool); no intermediate file to
generate for the compilation process (Makefile.in,
- Configuration: the configuration process is fast,
easy to control and to modify
- Flexibility: SCons can be extended easily thoughout
modules. Besides, helpers can be written easily to
help programmers (take all source files in a
directory, or check automatically the consistency of
the builds for example). SCons also has excellent
support for win32 and OSX platforms, it handles many
languages like Java or Fortran out of the box.
- Evolution: the API and the code written for
compiling the targets are re-usable so projects using
it will not be locked.
How do they compare to unsermake?
Unsermake is a replacement for make and automake only.
Bksys replaces the whole autotool chain.
Can you summarise the build system BoF at aKademy?
Several candidates were evaluated. QMake is way
too limited and cannot be used at all. Unsermake is
not to be kept, as it is only a partial solution and
emulating the behaviour of automake and make consumes
a lot of resources. Two solutions remained in
competition for the future KDE build system: CMake and
CMake is a Makefile generator like QMake; it uses a
macro language which is known to present several risks
as non-standard targets arise frequently in KDE. On
the other hand SCons is much more flexible as it is
based on Python, and was proven to work on fairly
complex applications already (KDE Games, Rosegarden,
..). SCons was then chosen and the conversion of
kdelibs 4 has started.
So what work needs to be done now?
So far, the main goal of bksys has been to replace
autotools for usual KDE projects. Now for kdelibs the
situation is a bit different as the tool will be the
base of all KDE applications, so a new framework has
to be designed, in particular:
- We have to agree on a new set of API (stardard
targets, naming, features...)
- New bksys modules have to be written for detecting
the system configuration (full autoconf replacement)
- Some work has to be done for writing config.h files
- More helpers will have to be written to make
programmers lifes easier (scan for sources
At the very moment, the bksys scripts have been added
to KDE SVN, and 3 main directories in kdelibs 4 are
already compiling (dcop, libldlt, kdefx). There is
some documentation in trunk/KDE/kdelibs/bksys/design.
The main aspects of the future framework are
presented, and some questions are left opened to
In the past, the kdegames module was converted in
about 2 days, but for kdelibs it will take a lot more
time as even after the framework is complete some
reverse-engineering will have to be done on the
Makefile.am to achieve the conversion. I am striving
at the moment to get a first version of the framework
ready (most configuration modules complete and a few
folders compiling) to show how the new system will
look like and the main advantages of using it.
Who is going to do the work?
.. or who is working on it already? Three people have
committed code on bksys in svn so far, Simon
Haussmann, Stephan Kulow and I. Interesting ideas have
been raised on the IRC, and I am awaiting
more comments, when the first version of the framework
is ready for testing (a request for comments will be
Are non-KDE projects taking up SCons/bksys?