Where to put KDE Frameworks cmake stuff...

[Stephen Kelly]

Hi,

I'm not certain we're understanding what the other is saying, and these 
emails are already too long and covering too many different subjects.

I'll just select a few things to respond to.

> But, whenever I try to introduce versioned install dirs, nobody here wants
> to have them, 

> so currently we can not install multiple versions into one
> prefix.

I do not understand why we can not install multiple versions of a library to 
one prefix.

>> Right, but one way of finding out if the feature is needed is to not have
>> it in 5.0, and see if people complain. If they do validly, then it can be
>> added in 5.1.
> 
> I'll write something.

I do not understand how your response relates to whether it is possible to 
add the feature in 5.1 if 5.0 doesn't have it. If people compain and we 
therefore learn reasons that it is the only/best way to have the feature and 
it is a real requirement, then we can add it.

> If you do
> find_package(KF5 COMPONETS KCoreAddons KWidgets)
>  
> then first KF5-cmake will be found somewhere in some prefix, and then the
> listed components will be only searched in the same prefix, and
> additionally in a shadowed prefix,

Is this for all users of it, or just the 'KDE' users? So I won't be able to 
have KCoreAddons in /usr/, KArchive in /opt/ and KItemModels in 
/home/stephen/ even if I wanted to?

> If you additionally do
> include(KF5BuildSpecs)
> this makes you follow the frameworks rules.
> So, if you have set CMAKE_INSTALL_PREFIX to /opt/kf5, where your
> KCoreAddons will have been found, you'll get the same install locations as
> what is already installed in /opt/kf5. 

> If you have set your
> CMAKE_INSTALL_PREFIX to something else, you'll get a cmake error.

Sounds inconvenient.

> If not doing this, you may have arbitrary versions of the libraries in
> various places on your system, where it may happen very well that cmake
> will find incompatible versions (happend at least with phonon and
> nepomuk).

I don't know the nepomuk case, but with phonon I thought the problem was 
that there actually were two incompatible versions of the library all the 
time. One provided by Qt, and one in kdesupport, which is the one kdelibs 
depended on.

>> Maybe there is a case for a cmake_maximum_version().
>> 
>> The command would define the maximum version which features can be used
>> from. This would solve the API-use problem, and coupled with policies,
>> possibly the behaviour-change problem. I'm also not certain if it's
>> feasible to do in cmake though.
> 
> Maybe.
> I'm currently not up-to-date about the state of cont./nightly builds of
> kdelibs. This would be one good way for making sure nothing gets broken,
> they would have to use the minimum required cmake version.

If this was enforced on the nightly builds level (where it can be ignored) 
it would not be as effective as on the cmake level (where it can not be 
ignored).

Thanks for your efforts,

Steve.