|
| faq flatforty contribute subscribe configure search rdf main |
Posted by Jonathan Riddell on Sunday 11/Sep/2005, @08:28from the do-we-get-to-keep-libtool? dept. 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 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:
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:
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... < | >
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| "That's something I don't know." -- David Faure | ||
| KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster. | ||