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.
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
