Build system for KDE4

[Alexander Neundorf]

Hi all, 

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 
on everything.
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)
yes

>  - generating shared libs (on all ELF platforms + MacOS X; Windows?)
yes

>  - icon installation
needs a custom macro (not yet written)

>  - uic, moc, KConfigXT, etc
yes

>  - 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 
before foo.

>  - manual hints for dependency resolution
Not sure. Can you explain more ? It is possible to manually add dependencies 
of files.

>  - 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
yes

>  - 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 (?)
yes

>  - multiple build targets (libfoo, libbar, libbaz) in one file
yes

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

possible

> Would be nice, but not necessary:
>  - having a standard and distributed build system and test suite

CMake supports a test system: 
http://www.cmake.org/Wiki/CMake_Testing_With_CTest
I haven't used it yet, so I can't say more about it.


>  - ability to build from svn:/trunk/KDE
Don't know.

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

Bye
Alex
-- 
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