Where to put KDE Frameworks cmake stuff...

[Alexander Neundorf]

On Saturday 21 April 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> >> instead of maintaining a list of 'known' components. This would make the
> >> FindKDEFrameworks some kind of 'reflector' for finding frameworks which
> >> adds consistency of versions etc.
> > 
> > I thought about this.
> > IMO it is a good thing to have a hardcoded list of known components in a
> > FindKF5.cmake, because this way this is is the place where a library is
> > officially marked as a "KDE frameworks library".
> > 
> > If we don't do this, there will be developers who will think this is the
> > way how libraries are searched in general, and start to install their
> > whatever libraries so that FindKF5.cmake can find it.
> > This will become a mess.
> 
> Good point.
> 
> > A lot of this is for providing the shared install locations.
> > 
> > I am not aware of a solution to provide shared install locations which
> > does not require installing some package which defines them.
> 
> I can think of a way for each framework to define them in each Config file.
> The problem then would be that different Config files might disagree.

Yes, there could still be the situation that a user defines for some 
frameworks library a custom install dir. Then we'd have an issue. But then I'd 
say this was done explicitely by the user, he has to figure out how to make it 
work.

> > So, if we want to keep this feature, we need some package which does
> > that. Since there is no one basic library, it looks like it must be a
> > separate package.
> > 
> > If you say we don't need shared install locations (a KDE frameworks-using
> > package picks up the custom install locations from the KDE frameworks it
> > is built against if it is installed into the same prefix), then please
> > first make sure that this feature is really not wanted - by frameworks
> > developers, by kde-core developers, by KDE SC developers, by 3rd party
> > KDE developers, by packagers, by users.
> > I added this feature on request from somebody, may have been packagers.
> 
> I think it was Volker. He's told me he's not sure it's still needed, but he
> hasn't emailed here. I'll try again to poke him about that.
> 
> That wouldn't tell us whether packagers or others find this feature useful,
> but it would surprise me if packagers used it. Can we ask?
> 
> I don't think this is an essential feature personally because there are
> much easier ways to create the same result. If it's defining everything
> about our build-system, I agree that we'd need to find out if it's still
> needed or not first.
> 
> We could ask on kcd, kde-devel and kde-packager to see if those groups are
> aware of, value or use the feature. But what question would we need to ask
> exactly?



> >> > This should ensure that a consistent set of KDE
> >> > frameworks libraries is found later.
> >> 
> >> Can't versioning ensure that?
> > 
> > How ? Simply requiring some version number ?
> > There can be still multiple versions of the same library installed. If we
> > introduce such a KF5 cmake package, normally, it won't be possible to
> > install multiple versions of the same library to the same prefix.
> 
> This isn't very clear to me.
> 
> You're saying that with the KDE5-cmake package and the install location
> magic, it would not be possible to install multiple versions of a library
> to the same prefix? That doesn't sound good for distros, so I guess
> there's more to it than that.

Good points.

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.

Ok, then there is now also Debian multiarch which doesn't make things 
easier...

I'll post the prototype/test in the next days.
 
> I'm also not sure what you mean by package. On debian systems, you can
> install multiple versions of libraries, but only one version of the headers
> (the -dev package). I think it's similar with rpm systems.
> 
> As this KF5-cmake stuff would be part of the -dev package on those systems,
> does that have any consequences?
> 
> Or are you talking about other scenarios like a developer building own
> stuff or distros which do not do such headers/libraries separation?
> 
> >> If we try without this common build-time dependency for the 5.0 release
> >> and find that it's really really needed, we can add it for 5.1, right?
> > 
> > As said above, I am not aware of another way to make the shared-install
> > dirs work.
> 
> 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.
 
> >> > This will also mean that the kde-modules/ subdir from e-c-m will go
> >> > away, this will be in the KF5 package. Then we have a clear separation
> >> > of stuff again.
> >> > 
> >> > 
> >> > Comments ?
> >> 
> >> I'd prefer it to be possible to download the KCoreAddons tarball and
> >> build and use it.
> > 
> > Yes. The one additional thing would be to install KF5-cmake to some
> > custom location, where you will also install your own versions of KDE
> > frameworks libraries.
> > While installing this KF5-cmake, you will explicitely decide whether your
> > set of libraries should be self-contained, i.e. not KDE frameworks
> > libraries available on the system may be used, or whether some designated
> > set of KDE frameworks libraries, e.g. the one installed on the system,
> > should be used and you want the libraries you work on shadow those, but
> > use the unshadowed ones from the system.
> 
> I'm understanding more what you're saying, but I'm not sure it's needed.
> Can't I just use CMAKE_PREFIX_PATH=/usr:$HOME/mykdestuffprefix and have a
> cmake wrapper script which uses
> 
> -DCMAKE_INSTALL_PREFIX=$HOME/mykdestuffprefix
> 
> ?
> 
> It seems sort of similar to the concept of workspaces with eclipse, is that
> right? I'm not more familiar with those, but it might help to understand
> and compare.

Me neither. So, maybe.

> > Without this explicit decision, such a setup is harder. The system
> > libraries will be found.
> 
> In the solution I wrote above, the decision is made when creating my
> wrapper scripts and environments.

I'm not a friend of having to set a whole bunch of environment variables, and 
especially not of wrapper scripts.
 
> So in your solution, I would install KCoreAddons into /opt/kf5 and then if
> I do a find_package(KCoreAddons), my install location would be set to
> /opt/kf5?

No, not at all. In this case you would simply use the KCoreAddonsConfig.cmake 
file, no magic at all, plain regular cmake behaviour.
 
> What if I also have KCoreAddons installed in /opt/myotherkf5 ? How would I
> decide which KF5-cmake-container-prefix to use? Environment variables and
> wrapper scripts?

As always, CMAKE_PREFIX_PATH.
If you are a user of KF5, and not part of KF5, i.e. not including 
KF5BuildSpecs.cmake, then nothing special happens.
You'll get the set of KDE-specific install location variables, set to their 
default values.

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, if this KF5 has been installed as shadowing an already 
existing one (intended for developers of a frameworks library).

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.
This way it is enforced that all KDE frameworks libraries are installed 
together (yes, one can still work around this by manually settings other 
install dirs in the cache).

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

> Is it possible to use multiple eclipse workspaces together, if that's
> relevant?
> 
> > I agree that having to install such a meta cmake package first may/will
> > feel strange. But I haven't found a better solution.
> > In the last years there were so many emails from people who had problems
> > with their phonon installation, because there were two copies: the one
> > from Qt, and the one from KDE. Some were found at build time, and some at
> > runtime. With a split kdelibs such issues will probably be much more
> > common. Debugging such problems and helping those people to adjust there
> > setup so that it works takes a lot of time and is no fun.
> > 
> > With such an explicit marker I think we can avoid such situations.
> > 
> > Maybe we can do something with ExternalProject() or downloading something
> > via file(DOWNLOAD ...) to make this process more straighforward.
> > 
> >> And ecm of course, though I would hope that most frameworks
> >> won't get so complex that they need a very recent ecm and can rely on
> >> distro provided ecm or similar - That's one reason I don't like required
> >> version sharing. If knewstuff (very high in the dependency tree)
> >> requires a new version for some reason it will result in a new version
> >> requirement for kcoreaddons (very low in the dependency tree), though
> >> it is not needed.
> > 
> > I would see KDE frameworks as one coherent set.
> > Let's say knewstuff decides to require CMake 2.10.
> > It will happen that the developers then install a KNewStuffConfig.cmake
> > which makes use of CMake 2.10 features.
> > If this file should be findable by a FindKF5.cmake, this means that
> > FindKF5.cmake now requires CMake 2.10, with a lower cmake version it will
> > get a cmake error while processing KNewStuffConfig.cmake.
> > 
> > Also, let's say somebody uses cmake 2.10 on some project which just says
> > cmake_minimum_required(VERSION 2.8.8), and no additional policy settings.
> > He may get some new policy warning, and because fixing warnings is a good
> > thing, he fixes it. But it is possible that this fix makes the project
> > incompatible to cmake 2.8.8, and it now actually requires 2.10, and he
> > broke it for everybody who uses the required version.
> 
> 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.
 
> > This is the reason why FindKDE4Internal.cmake did not only set the
> > required cmake version, but also adjusted policy settings of newer cmake
> > versions.
> > 
> >> All that said, I'm not going to stand opposed to you on this. I'm a -0
> >> on the decision making scale django uses:
> >> 
> >> http://readthedocs.org/docs/django/en/latest/internals/contributing/bugs
> >> - and-features.html#how-we-make-decisions
> >> 
> >> We could, if so motivated, consider how it affects
> >> frameworks-buildsystem maintainers, frameworks maintainers, frameworks
> >> users, kde application- buildsystem maintainers and kde application
> >> developers
> > 
> > Definitely.
> > 
> > If "KDE frameworks" is more than just a number of libraries which build
> > on Qt, then it makes sense to enforce some rules.
> > If it is just a number of libraries using Qt, no such rules are needed,
> > and we can get away with much less work (pushing more work on the
> > individual developers and users).
> 
> Can that work be largely or entirely encapsulated in the 'KDE consistency
> layer'? If so, then the problem is solved for KDE application developers,
> which is the primary use-case for frameworks.

This really depends a lot on the common-install-dirs feature.
If we really want to have it, it must be there before anything else, and 
cannot be added on top.
 
> For other frameworks-using developers, they'll either
> 
> * have less complicated set-ups and dependencies/requirements and therefore
> not need the elephant-gun
> * have equivalent complexity with a different packaging solution for their
> whole system (including the non-Qt/non-KDE parts),
> * have equivalent complexity and therefore using the 'KDE consistency
> layer' would make sense to them


I'm not sure I understand which cases you are comparing here.

Alex