KDE Core/Platform 11/Buildsystem

Issues and wishes regarding the buildsystem

We discussed with the following participants:

• Sune (Prison, Debian)
• Ismael (OpenSUSE)
• Harald (Phonon, Amarok)
• Raphael (FreeBSD)
• Stephen (Grantlee, KDE)
• Gregory (BetterInbox, Windows)
• Georgy (Debian)
• Andreas (KDE)
• Alex (CMake)

Upstreaming

When cmake was introduced to KDE, there were not many other free projects using cmake. So the cmake f iles were added to kdelibs, and so were available for "all" KDE developers. The situation hsa changed in the last 5 years, and now there are also many free software projects outside KDE, and they'd like to use some of the cmake stuff from KDE. So, how can more be made available ?

Conclusions

• some things may qualify to move directly into CMake
• getting a Find-module into CMake is not easy, but straightforward:
  • "adopt" a module and send an email to [email protected] saying "I volunteer as maintainer for this new module".
  • if this is accepted, you'll have to maintain that module in CMake in the future, i.e. fix bugs reported by cmake users in the cmake bug tracker, care for source compatbility etc.
  • once a module is in cmake and a version of cmake which has this module is released, we cannot make use this before we require this version of cmake as minimum for KDE, and we shouldn't increase this too often.
• some things are too specific to be accepted in cmake

Actions

• try to get automoc into cmake
  • port it away from Qt to STL and kwsys, Kitwares process-class (Gregory)
  • discuss on [email protected] the best way how to integrate this in cmake (Alex)

• create a separate package which contains just cmake modules
  • move the stuff which will not go into cmake from kdelibs there (Alex)
  • make frequent and regular releases - help needed
  • set up an own project or join an existing project ?
    • https://github.com/rpavlik/cmake-modules or
    • http://code.google.com/p/cmake-modules/source/list , seems to be dead

• check whether MacroLogFeature.cmake can be replaced by FeatureSummary.cmake
  • evaluate FeatureSummary.cmake from cmake 2.8.4 and if necessary propose extensions (Stephen)

Packaging questions

Thanks to the participation of several packagers some questions could be answered.

Installing outside CMAKE_INSTALL_PREFIX

When a package is installed, is it allowed that it installs any files outside CMAKE_INSTALL_PREFIX ? (e.g. Qt designer plugins will not be found and thus useless when installed anywhere except the Qt location)

Answer: no, nothing must be installed outside CMAKE_INSTALL_PREFIX by default. If necessary, e.g. for Qt designer plugins, it is recommended that the package prints a message which tells the one who installs that it will not work that way and what options he has to make it work. E.g.

Warning: Qt designer plugins are installed to /opt/foo/lib/plugins/, they will not be found by Qt designer. You can

• set QT_PLUGIN_PATH to include /opt/foo/lib/plugins/
• set the cmake variable DESIGNER_PLUGIN_INSTALL_DIR to /usr/lib/qt/plugins/

Configurable install locations

Currently it is possible to configure the install locations for include files, libraries and everything else to completely different, independent directories. When installing such a library, a cmake-based library should install a Config.cmake file. Under Linux/UNIX it is convenient to write the full install directory into the cmake Config-file. This is not good under Windows. There users want to be able to specify the install location when they install the binary package. In this case a full path in the Config-file does not work, there it must be relative. That's why: is it necessary to make the include files and library install directories completely configurable ?

Answer: No, it's not. The packager can't think of any reason to install the headers and libraries to different prefixes. This does not apply to e.g. SYSCONFIG_INSTALL_DIR (i.e. /etc/), which stays fully configurable.