ANNOUNCE: experimental support for building kdelibs 4 with cmake
Alexander Neundorf
neundorf at kde.org
Sun Jan 15 18:59:58 CET 2006
Hi,
maybe you have noticed, I have added CMakeLists.txt to trunk/kdelibs/.
With these files kdelibs/ can be built using cmake (http://www.cmake.org) (not
yet).
After some discussion on kde-buildsystem at kde.org this week
( http://mail.kde.org/pipermail/kde-buildsystem/2006-January/000410.html
http://mail.kde.org/pipermail/kde-buildsystem/2006-January/000412.html
http://mail.kde.org/pipermail/kde-buildsystem/2006-January/000447.html
http://mail.kde.org/pipermail/kde-buildsystem/2006-January/000453.html )
in which I was encouraged to try to build kdelibs using cmake, I started
working on this task.
We have also the support from the cmake developers, both Brad King and Bill
Hoffman subscribed to the kde-buildsystem mailing list:
http://mail.kde.org/pipermail/kde-buildsystem/2006-January/000444.html
http://mail.kde.org/pipermail/kde-buildsystem/2006-January/000445.html
http://www.kitware.com/profile/team.html .
cmake is an open source software build system, designed to replace autotools
and with a special emphasis on portability. Currently it is developed by
employees of Kitware Inc., they use it to build there own cross-platform
software products (mainly ITK and VTK, see http://www.kitware.com), so the
situation is not that much different to Qt and Trolltech. cmake supports
different buildsystems: makefiles (GNU, BSD, MS, Borland) and project files
for MSVC 6,7,8, XCode 2 and KDevelop3. Among others it handles automatically
the dependencies of libraries and executables which link to them in one
project (i.e. kdelibs).
Here you can find more information about cmake:
http://www.cmake.org
http://www.cmake.org/HTML/Documentation.html
http://www.cmake.org/mailman/listinfo/cmake
-------------------------------
Preparation:
-------------------------------
1) get cmake from cmake cvs and install it:
-------------------------------------------
$ 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
(as usual: configure, make, make install)
2) check out trunk/KDE/kdesdk/cmake
This directory contains the cmake scripts (in cmake language: "modules")
needed to compile KDE using cmake. Installation is still manual: copy the
files you find in kde3/, kde4/ and modules/ all directly into the system
cmake module directory (usually /usr/local/share/CMake/Modules/ ), not into
subdirectories !
3) Run cmake for kdelibs:
$ cd src/KDE/kdelibs/
if you want to use kdevelop:
$ cmake . -GKDevelop3
if you want to use XCode:
$ cmake . -GXcode (use the cmake help if the name of the generator is slightly
different)
if you want to use Makefiles:
$ cmake .
if you want to use MSVC: run CMakeSetup
Then cmake will run and execute a host of configure checks.
If this succeeds, you will then be able to build kdelibs/, so either start
make, or XCode, etc.
Currently nothing will be built, because it is commented out in
kdelibs/CMakeLists.txt, I wanted to get the configure checks complete first.
In theory the configure checks should work on all platforms supported by
cmake, i.e. linux, BSD, any UNIX, Mac OS X, Windows. But practically I guess
the checks will have to be tuned a bit to work especially on Windows.
-------------------------
The current state:
-------------------------
All the CMakeLists.txt committed to kdelibs/ have been autogenerated with
kdesdk/cmake/am2cmake:
$ cd src/KDE/kdelibs
$ am2cmake --kde4 (the "--kde4" parameter is important !)
This script handles:
-creation of executables
-creation of shared libraries
-creation of plugins
-install rules for most filetypes
-adding most/some include directories as specified in Makefile.am
-adding most/some libraries to link to as specified in Makefile.am
-the --enable-final option
-the conditional build of test executables
-creation of a rule for doxygen
-creation of install rules for icons
-rules for ui, ui3, ui4, moc, kcfg, dcop stubs and skel
Issues/problems/open questions:
----------------
Most install rules specify the target directory using a variable, except the
install rules for executables, libraries and plugins. There the install path
is given directly relative to the installation prefix, i.e. "/bin" for
executables, "/lib" for libraries and "/lib/kde3" for plugins. Are variables
required for this ? I mean, there is a variable for the installation
directory, and is it nevertheless required to have these three install
location in variables ?
-----------------
It doesn't convert custom rules found in Makefile.am's, so these have to be
added manually.
------------------
It doesn't recognize various variables used in Makefile.am's, e.g. variables
for include directories of software packages and other things like this, so
this has to be adjusted manually.
---------------------
It doesn't recognize conditions in the Makefile.am's, so these have to be
added manually.
-----------------
I haven't implemented support for meinproc yet. How do these rules look like ?
------------------
Having multiple targets with the same name in one project is not possible with
cmake, e.g. libkdevelop.so and kdevelop have both the target name "kdevelop"
in cmake. As workaround the executable kdevelop has to become the target
"kdevelop_executable" (or something like this) and the property "OUTPUT_NAME"
of this target has to be set to "kdevelop". Then it will produce both a
libkdevelop.so and a executable kdevelop.
--------------------
The install commands in cmake are not very powerful yet. The cmake developers
know this and plan to improve them.
------------------
The build commands are all prefixed with "kde4". There is a cmake module for
KDE 3 (FindKDE3.cmake) and one for KDE 4 (FindKDE4.cmake). Currently the
commands in FindKDE3.cmake are prefixed with "kde3" and the commands in
FindKDE4.cmake are prefixed with "kde4". This makes it obvious for which
version of KDE they can be used, and it would be possible to build KDE 3 and
KDE 4 (and KDE 5, 6 etc.) software within one project.
OTOH it means "search and replace" if the major version number increases. I
would prefer the kde3/kde4 prefixes, but I don't have a strong opinion on
this.
What do you prefer ?
---------------------
The syntax for listing source files is different than in Makefile.am:
xxx_SOURCES = main.cpp interface.cpp widget.ui config.kcfg interface.skel
METASOURCES = AUTO
in cmake:
set(xxxSources main.cpp interface.cpp)
kde4_add_ui_files(xxxSources widget.ui)
kde4_add_kcfg_files(xxxSources config.kcfg)
kde4_add_dcop_skels(xxxSources interface.h)
kde4_automoc(xxxSources)
My main reason for not mixing them all together is the handling of the dcop
stubs and skeletons. For me it was very confusing that with "interface.skel"
a filename was given in the list of source which doesn't exist and which will
never be created during the build. IMO this is hard to understand: "well, if
you want to build dcop skeletons, make up a hypthetical filename acccording
to this and that rule, and add it to the list of sources, then the
buildsystem will magically guess what you meant by it and do something."
IMO although it is more typing
kde4_add_dcop_skels(xxxSources interface.h)
it is very obvious and IMO for the average programmer (at least for me) it is
easier to follow what will happen, since I see a concrete function name
("kde4_add_dcop_skels()") in this line. With this function name I can search
for this function in the cmake modules to see/improve/debug its
implementation. I think this avoides the "Convenience Trap" as Matthias put
it (http://doc.trolltech.com/qq/qq13-apis.html).
If we don't find a better way than to make up non-existent filenames for the
dcop stuff, I really think this way with the explicit function calls for each
type of files is the better option.
So, I hope I didn't forget too many things and you are all informed now.
Please have a look at the created files and let's discuss the "API",
preferrably on kde-buildsystem at kde.org.
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
More information about the Kde-buildsystem
mailing list