This reverts commit 7c5e2e49ae.
In KF5, C++11 is not to be assumed on all our platforms. So don't force
it from cmake. That said we have to make sure our code builds in both
case (C++11 available or not). I'll get in touch with the build.kde.org
admins to sort that out.
CCMAIL: ivan.cukic@kde.org
- Installs PlasmaConfig, FindPlasma, PlasmaMacros, etc.
- find_package Plasma works
- version set to 2.0.0, do we dare that?
This might bump into FindPlasma.cmake, which is installed by kdelibs,
and should be removed: it applies to Plasma 4.1 only and bails out,
since after that, we used the KDE4 libs find_package foo. Now we're kind
of going back to pre-4.2 times. :-)
Make it possible to install any type into any path prefix. We just add
an optional argument to also specify the type, so from now on installed
service files will not all be plasma-applet-<pluginname>.desktop, but
for example plasma-wallpaper-<pluginname>.desktop.
CCMAIL:plasma-devel@kde.org
I thin using the variables is safer, this way you are somewhat guarded against changes
in the names of targets, and a typo leads to an empty variable, instead to
"ld: cannot find -lkcoreaddons" which looks very much like a missing normal library
Alex
All cpp code moves into the src/ subdirectory, as the Frameworks policy
suggests.
Directory structure should now be in line with other, future frameworks.
kdelibs frameworks now installs a KDELibs4Config.cmake, which
can be searched more or less normally using
find_package(KDELibs4 NO_MODULE)
Preparing CMAKE_MODULE_PATH is no longer necessary.
KDELibs4Config.cmake does not anymore containg compiler or cmake settings,
so must now load these settings:
find_package(KF5... CMake Compiler)
Alex
- remove usage of old macro_*() macros
- testing for kdelibs_SOURCE_DIR doesn't make sense here, this is only set inside a project(kdelibs)
- don't append a subdir to ${CMAKE_PREFIX_PATH}, this is a list of directories
- don't add ${CMAKE_SOURCE_DIR}/cmake/modules/ to CMAKE_MODULE_PATH, this directory doesn't exist
Alex
