[dot] KDE to Migrate to bksys/SCons Build System

[Dot Stories]

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

From: Jonathan Riddell <>
Dept: do-we-get-to-keep-libtool?
Date: Sunday 11/Sep/2005, @10:28

KDE to Migrate to bksys/SCons Build System 
===========================================

   At the build system BoF at aKademy is was decided to start moving the
KDE 4 build system from unsermake
[http://www.kde.me.uk/index.php?page=unsermake] to the SCons/Python
[http://www.scons.org/] based system bksys
[http://www.kde-apps.org/content/show.php?content=19243].  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
[http://freehackers.org/~tnagy/kdissert/], a mind-mapping tool for the
creation of documents and its build system bksys
[http://freehackers.org/~tnagy/kdissert/bksys.html].
     What is SCons and what is bksys?

     SCons [http://www.SCons.org/] 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.
[http://conference2005.kde.org/slides/software-construction-tools-talk--thomas-nagy.pdf
]
     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?
 [http://www.kde.me.uk/index.php?page=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
[http://websvn.kde.org/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
[http://www.rosegardenmusic.com/], kio-locate, skim...
 [http://kde-apps.org/content/show.php?content=14597]