Build system for KDE4
neundorf at kde.org
Mon Jun 13 19:07:11 BST 2005
On Monday 13 June 2005 06:25, Chris Lee wrote:
> This is clearly a problem and since KDE4 is an aggressive new
> major release, we should solve it in the KDE4 timeframe. We don't
> want to have to wait until KDE5 for a build system that doesn't
> suck, do we?
> Without further ado, the notes from the discussion.
Ok, here my take on cmake. I'm no expert in linking issues, so I can't comment
Until now I managed to compile and link complete kdevelop using cmake.
Currently I'm improving the kdevelop/cmake/am2cmake (ruby) script, which
reads all Makefile.am's starting from the current directory and generates
CMakeLists.txt from them. It already works quite well and I am already quite
far with compiling kdebase with the autogenerated cmake files. am2cmake
currently isn't able to find out to which libs a target in Makefile.am links,
so this has to be adjusted manually in the CMakeLists.txt
> Must support:
> - generating binaries (duh)
> - generating shared libs (on all ELF platforms + MacOS X; Windows?)
> - icon installation
needs a custom macro (not yet written)
> - uic, moc, KConfigXT, etc
> - GCC visibility
what does this mean for the buildtool ?
> - automatic dependency resolution
I'm not sure I understand exactly what you mean. If I say application foo
links to library libbar.so, cmake detects that libbar.so has to be compiled
> - manual hints for dependency resolution
Not sure. Can you explain more ? It is possible to manually add dependencies
> - flex/bison
needs a custom macro similar to the ones for uic, moc, kconfig_compiler etc.
> - non-recursive (flat) builds
The cvs version features non-recursive builds since some weeks
> - --enable-final
with a custom macro, probably
> - builddir != srcdir
> - simple to the point of being learnable within 5 minutes
I can't warrant the 5 minutes, but IMHO it's easy to learn. Central
documentation on www.cmake.org
> - kdeinit support (?)
> - multiple build targets (libfoo, libbar, libbaz) in one file
> - --compile-slots, like in unsermake
what's this ?
> - pkg-config support
If you want to use pkg-config with cmake, you are free to do so. But it can
also be done without pkg-config.
> - support rpath sanely
cmake supports rpath. I don't know what exactly you mean with "sanely".
> - ability to link & run uninstalled binaries
Not sure. At least it adds the rpath. As I said, I'm no linking expert.
> - easily integrated into KDevelop
Well, does it count that cmake can generate kdevelop project files ?
> - 'admin' needs to be shipped in KDE instead of in src of each app
> (if we keep the 'admin' dir, that is)
> Would be nice, but not necessary:
> - having a standard and distributed build system and test suite
CMake supports a test system:
I haven't used it yet, so I can't say more about it.
> - ability to build from svn:/trunk/KDE
> support for something like "make install DESTDIR=/tmp/kde-buildroot" to
> keep packagers happy
I.e. changing the install path after compilation ? You can change the
CMAKE_INSTALL_PREFIX and then it will be installed there.
> crosscompiling (At least if we care about Opie and the likes reusing KDE
> base libs -- would be nice IMO)
It is possible to use cmake for cross-compiling. I do this every day but in a
quite special setting (http://www.neundorf.net/cmake/). I also did some
cross-compiling for Linux with cmake. But I can't tell how easy it would be
to apply this to a KDE build system.
> Users should be able to select stuff like --with-pam/--without-pam easily
> (without editing Makefiles or the likes), and where possible this stuff
> should be autodetected while keeping it overridable..
cmake features a GUI for adjusting variables (one version for curses, one for
MFC, one for wxWidgets)
Additional features of cmake:
-no other tools (no shell, no perl, no m4, no python, no automake, no libtool,
no autoconf, no autoheader, no aclocal,...)
-creates various types of build-files: Makefiles, XCode project files, MSVC
project files, if you want you can add a scons-file generator ;-)
Currently there are two problems with cmake remaining.
1) currently it can't handle multiple targets with the same name in one
project tree. In cmake the name for a library target is just the actual name,
without the pre/suffix. So libkdevelop.so is "kdevelop", and the application
"kdevelop" is also "kdevelop". There's a good chance that cmake 2.2 (the next
released version) will offer a fix for this.
2) libtool convenience libraries
They are not really supported by cmake. I don't know if they are actually
required for anything. There are the following solutions/workarounds:
-add support for conv. libs to cmake
-write some clever macro which works good enough for us
-an extension to cmake which allows to retrieve the object files contained in
a static library and link to them
If you want to have a look at some cmake macros, look at
kdevelop/cmake/KDE.cmake and kdevelop/cmake/KDEMacros.cmake. For some simple
configure checks look at kdevelop/ConfigureChecks.cmake . For some example
cmake files look at the various CMakeLists.txt under kdevelop/.
If they look too complicated it would be of course possible to merge almost
all of the calls into some magic macro, but I'd prefer not to do this, but
keep this more obvious and somewhat more lengthy style. IMO this is easier to
understand, since you can simply look up all of the commands on the cmake man
To get current cmake:
cvs -d :pserver:anonymous at www.cmake.org:/cvsroot/CMake login
(respond with password cmake)
Follow this command by checking out the source code:
cvs -d :pserver:anonymous at www.cmake.org:/cvsroot/CMake co CMake
Work: alexander.neundorf at jenoptik.com - http://www.jenoptik-los.de
Home: neundorf at kde.org - http://www.kde.org
alex at neundorf.net - http://www.neundorf.net
More information about the kde-core-devel