Where to put KDE Frameworks cmake stuff...

[Stephen Kelly]

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.

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

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.

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

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

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?

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?

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.

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

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

Thanks,

Steve.