From kde-core-devel Sun Jan 15 17:59:58 2006 From: Alexander Neundorf Date: Sun, 15 Jan 2006 17:59:58 +0000 To: kde-core-devel Subject: ANNOUNCE: experimental support for building kdelibs 4 with cmake Message-Id: <200601151900.01363.neundorf () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=113734805302055 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@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@www.cmake.org:/cvsroot/CMake login (respond with password cmake) Follow this command by checking out the source code: $ cvs -d :pserver:anonymous@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@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