Where to put KDE Frameworks cmake stuff...

[Alexander Neundorf]

On Wednesday 25 April 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> >> I do not understand why we can not install multiple versions of a
> >> library to one prefix.
> > 
> > E.g. because we don't have versioned include dirs, so there can be only
> > one version in one prefix (talking about development installations).
> 
> Right, you were talking about development (with includes) installations.
> That answers a question I asked previously at least (when I mentioned -dev
> packages etc).
> 
> > But, if you do
> > find_package(KCoreAddons NO_MODULE)
> > find_package(KArchive    NO_MODULE)
> > find_package(KItemModules NO_MODULE)
> > you can do whatever you want.
> 
> Ok, cool. I'm just wondering what restrictions are being imposed. We can
> have multiple layers of KDEDIRS env var, right? If you're restricting
> KDEFrameworksConfig.cmake to only two levels, that could have more
> consequences.

I thought more about it.
How about that:

find_package(KF5 COMPONENTS kcore kwidgets kitemmodels)

searches in the normal cmake way for kcoreConfig.cmake, using 
CMAKE_PREFIX_PATH and all that. Additionally automatically also using KDEDIRS.

Once it has found the first requested component, the remaining components are 
searched first in the same prefix as the first one, and after that in KDEDIRS, 
and in no other directories, no CMAKE_PREFIX_PATH etc.

This way, without having KDEDIRS set, libraries from KDE frameworks will all 
be found in the same prefix.
If you want to search in multiple directories, you can adjust the KDEDIRS 
environment variable.


Now that it seems the shared-install-dirs feature can be removed, this could 
be good enough.
It would imply that e-c-m will be updated relatively often and that the kde-
modules/ dir in e-c-m will indeed be quite KDE-ish.

 
> >> >> Maybe there is a case for a cmake_maximum_version().
> > 
> > Sure, but it it's easy to do, and doesn't require changes in cmake code
> > now and all the future (kind of backwards policy).
> 
> Do you mean 'isn't' and 'does require...'? 

Ehhh...
I mean "using the minimum required cmake version for nightly builds is easy to 
do."
and
"Adding cmake_maximum_version_features() requires changes in cmake code now 
and in all the future, which I think would be a lot of work, especially 
considering the fact that a similar effect can be reached by using the minimum 
required cmake version for nightly builds."

Ah, I see.
I was referring to the statement a bit more above.

Alex