Development/CMake KDE 4 2

Changes in the buildsystem from KDE 4.0/4.1 to KDE 4.2

Starting with KDE 4.0.0 source compatibility is guaranteed, this doesn't apply only to the C++ sources, but also to the CMake interface.

Incompatible Changes

1. The reduced link interface, details see below. It may be possible that an application which linked against KDE 4.0/4.1 now fails due to unresolved symbols. In this case the libraries which provide these symbols have to be added to the TARGET_LINK_LIBRARIES() calls. This happens only if symbols are used but the library is not linked again. This can be considered a bug in the cmake files of these applications. Applications which explicitely link against all libraries they use will build successfully with KDE 4.2.

Other Changes

Required CMake Version

At least version 2.6.2 of CMake is required now. With KDE 4.0 and 4.1 version 2.4.5 was required.

Removed option KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT

The option KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT was new in KDE 4.1 and enabled the reduced link interface. This is now always the case, so the option became unnecessary.

Removed option KDE4_USE_ALWAYS_FULL_RPATH

KDE4_USE_ALWAYS_FULL_RPATH was by default on. In this case executables, libraries and plugins where linked with RPATH. This caused relinking of these binaries during make install, which takes some time. If it was off, only executables where linked with RPATH, and their RPATH had to be sufficient also for the shared libraries and plugins. This can be the case, but doesn't have to. Applications which were not marked as RUN_UNINSTALLED where built directly with their install RPATH. This saved a lot of time during make install but the resulting install might not get the correct libraries. Since version 2.6 CMake can now edit the RPATH inside binaries, which compared to relinking takes no time. That's why this option is not necessary anymore, and now all executables, libraries and plugins are always built with their build tree RPATH and then installed with their install tree RPATH, so they always get their correct libraries, both when executed from the build tree as well as when executed from the install tree.