KDE Core/Platform 11/Buildsystem

From KDE Community Wiki

Warning

This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made. Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.


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)
  • check whether MacroLogFeature.cmake can be replaced by FeatureSummary.cmake
    • evaluate FeatureSummary.cmake from cmake 2.8.4 and if necessary propose extensions (Stephen)
  • improve support for adding an uninstall target (Alex)


Modular builds

Conclusion

  • every library should install a FooConfig.cmake file
  • so you can do for every library find_package(kimap) etc.
  • there should be a find_package(KDELibsModular COMPONENTS kdecore kimap) etc.
  • full modularization has benefits:
    • minimal dependencies for developers who want to use only very few or one library from KDE
    • robust and straight forward build
    • cdash dashboards and notifications just work
    • creating packages using cpack should just work
  • but also disadvantages:
    • more work, multiple repositories must be checked to be set up correctly instead of only one (kdelibs)
    • building them all manually becomes very hard -> a tool like kdesrc-build or CMake SuperBuild becomes basically necessary
  • alternatively building a bigger repository all in one or as parts is also possible, but this also has downsides:
    • not as straightforward, i.e. the required cmake code is trickier
    • there are multiple ways how stuff can be build, so they can break. I.e. we would have to ensure using nightly builds that both the all-in-one as well as the separate builds stay working

Tasks

  • write a "perfect" example how it should be done (Alex)
  • try to make cmake usable instead of pkg-config in autotools projects (Alex, Ismael)
  • put "SuperBuild" CMakeLists.txt somewhere in git (Alex)
  • make configure-checks more local, i.e. in the subdir where they are needed, instead of the toplevel CMakeLists.txt (???)



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.


Other things

  • is it necessary to check for Phonon when finding kdelibs ?
  • is perl still required ?
  • can we write a cmake function which helps with exporting symbols under Windows (and UNIX) ? (Stephen)
  • make building libraries statically fully and officially supported, at least for some libs (Win CE)
Retrieved from "https://community.kde.org/index.php?title=KDE_Core/Platform_11/Buildsystem&oldid=12975"