Where to put KDE Frameworks cmake stuff...

[Stephen Kelly]

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?

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

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

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

> This should ensure that a consistent set of KDE
> frameworks libraries is found later.

Can't versioning ensure that? 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.

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

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

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 which are distinct 
but overlapping groups, but I'm not certain we'd agree anyway. 

So if no one else opposes your plan, you should go ahead with it.

Thanks,

Steve.