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 build rules.

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 description files.

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 goals.

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 (autotools)
• 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, Makefile)
• 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 SCons.

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 automatically..)

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 discuss.

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 posted).

Are non-KDE projects taking up SCons/bksys?

Most projects using SCons do it directly and use their own framework, like Blender or Rekall. The projects using the bksys layer i know of are almost all KDE-oriented: Rosegarden, kio-locate, skim...

<  |  >