Where to put KDE Frameworks cmake stuff...

[Alexander Neundorf]

Hi,

On Saturday 21 April 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > Hi,
> > 
> > so here's my proposal:
> > 
> > * we will have a separate KF5 package, which will be a build-time
> > requirement for building KDE frameworks libraries. It will offer the
> > following features
> > ** KDE approved compiler settings
> > ** KDE conforming install dirs
> > ** finding consistent installations of the KDE frameworks libraries
> > ** supporting a base and a shadowing KDE frameworks libraries
> > installation (e.g. kcore from the system + kwidgets from the user,
> > shadowing the kwidgets from the system)
> > 
> > * every KDE Frameworks library will depend at build-time on this KF5
> > package
> 
> We agreed before that this stuff would be in ecm, not somewhere separate.
> Did new information come available to change that?

Yes.
I wrote tests/prototypes (not shared anywhere yet), and that's my current 
conclusion.

> > * every KDE Frameworks library will install a KFooConfig.cmake file,
> > which will have neither dependencies to e-c-m nor to KF5
> > 
> > * any application is free to use the installed KFooConfig.cmake files
> > directly without introducing any additional dependencies:
> > find_package(KFooConfig NO_MODULE)
> > 
> > * there will be a FindKF5.cmake, which every application must use which
> > wants to get the full KDE features, like install dirs etc., All the KDE
> > frameworks libraries will be known to FindKF5.cmake as components:
> > find_package(KF5 MODULE COMPONENTS kcore kwidgets)
> 
> I don't think it makes sense for the FindKF5.cmake file to store a list of
> known frameworks, because it would get out of date. I'd prefer to use the
> same plan as Qt5 will use:
> 
> find_package(Qt COMPONENTS Core Gui Script)
> 
> which does something similar to (I didn't look it up):
> 
> foreach(_component ${FIND_COMPONENTS}) # Similar for optional ones
>   find_package(Qt${_component})
> endforeach()
> 
> So we would have:
> 
> find_package(KF5 COMPONENTS CoreAddons WidgetsAddons)
> 
> or
> 
> find_package(KDEFrameworks COMPONENTS CoreAddons WidgetsAddons)
> 
> and
> 
> foreach(_component ${FIND_COMPONENTS}) # Similar for optional ones
>   find_package(K${_component})
> endforeach()
> 
> 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.

This should not be done.
I did such a mistake with KDE4.
kdelibs installs a whole lot of find-modules, and adds this directory 
automatically to CMAKE_MODULE_PATH.
Result: developers think this is the way how packages are searched. And 
install Find-modules on their own and builds fail if somebody does not add 
those directories to CMAKE_MODULE_PATH or if things are installed into 
separate directories.

I don't want to make such a mistake now again, pretend that some special 
solution is the right generic solution.

So, a FindKF5.cmake should search only libraries which belong to KF5.
If we can't decide whether a library is KF5 or not, then IMO there is no KF5, 
but a set of independent libraries.

> > This will provide the set of install dirs, compiler flags, ensuring that
> > libraries are found which are compatible.
> > 
> > * by installing a KF5 to some prefix, this prefix is "marked" as an
> > install location of KDE frameworks.
> 
> Can you say why such marking is needed?
>
> > Every KDE frameworks library which is
> > built against this KF5, must use the same install prefix.
> 
> Can you say why this is needed? Does Qt also have to be in the same prefix?

No, Qt is not a KDE frameworks library.

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.

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. They 
expected that if they installed kdelibs and set up their install locations in 
some way in kdelibs (e.g. for the .desktop files), that additional packages 
which were built against this package and installed to the same location would 
automatically use the same install dirs.
 
> > By doing this, it will get the same set of install locations as have been
> > set when KF5 has been installed.
> 
> Can this can be achieved without the above?

I can only come up with a solution where some package defines those dirs. If 
you can find a different solution, I'd be happy about it.

> > 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. Each installed KF5 
will find only those libraries which have been built against it. And 
additionally a defined set opf "shadowed" (typically distro-provided) 
libraries.

> Or do you mean for developers who are
> building things from git?
> 
> > * KF5 will provide a file KF5BuildSpecs, which should be used by KDE
> > frameworks libraries. This provides: a common required cmake version (so
> > we can rely on features and behaviour), a common required e-c-m version,
> 
> I'm not a big fan of sharing required versions like that.

Such a number can be there. Whether a package makes use of it is a different 
question.
IMO, at least for KDE frameworks, common versions of Qt and CMake should be 
required. Otherwise it will become a mess.
I work on library A and B one day, want to do something on library C the next 
day, and can't because I have to update Qt or cmake first.
Shared required versions should increase the burden to require a newer 
version.

> > and common version numbers. All these are only active if the using
> > library does include(KF5BuildSpecs) and then actually uses the provided
> > variables.
> 
> 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.

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

Without this explicit decision, such a setup is harder. The system libraries 
will be found.

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.

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

Alex