Where to put KDE Frameworks cmake stuff...

[Alexander Neundorf]

On Tuesday 24 April 2012, Stephen Kelly wrote:
> 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.

Same here.

> > 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.

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, 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.

Maybe I replied after the wrong section.
You know, these long emails... ;-)

> > 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?

Yes, this wouldn't be possible using FindKF5.cmake.
Seriously, why would you need that ?
I surely would not want anybody to want that.
The one is /usr would probably be the one from the distro.
The one in /home/stephen/ would be your self-compiled one, so I would assume 
you know what you are doing.
How should that mix with an install from some other 3rd party ?

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.


> > 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.

Depends on the definition of convenient.
It requires some effort from the developer (== inconvenient), but therefor 
makes sure you don't end up with some random mix of found libraries, but a 
most probably working one, because it was installed intentionally together (== 
convenient).

> > 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.

There are/were problems because users/developers have multiple versions 
installed, and not always combinations were found which work together.
I don't remembe the exact details, but there were mixes of distro vs. self-
compiled installations, 32 vs. 64 bit may have been issues, different versions 
in the different package-systems of the BSDs or OSX, etc.

Debugging this and helping people to get a working setup is no fun.

And, this is my main point, I see the same set of problems coming with a 
completely split up kdelibs, just much more often and for many more libraries 
if we don't do anything to ensure we get a matching combination.

I don't want to do email support for such setups as you describe above
(such support is a big part of the work I'm doing since the switch to cmake).

If we don't want to enforce anything, then please somebody raise the hand who 
will do the support e.g. on kde-buildsystem for those who experience problems.

> >> 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).

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).

Alex