Where to put KDE Frameworks cmake stuff...

[Alexander Neundorf]

On Thursday 26 April 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > I thought more about it.
> > How about that:
> > 
> > find_package(KF5 COMPONENTS kcore kwidgets kitemmodels)
> > 
> > searches in the normal cmake way for kcoreConfig.cmake, using
> > CMAKE_PREFIX_PATH and all that. Additionally automatically also using
> > KDEDIRS.
> > 
> > Once it has found the first requested component, the remaining components
> > are searched first in the same prefix as the first one, and after that in
> > KDEDIRS, and in no other directories, no CMAKE_PREFIX_PATH etc.
> > 
> > This way, without having KDEDIRS set, libraries from KDE frameworks will
> > all be found in the same prefix.
> > If you want to search in multiple directories, you can adjust the KDEDIRS
> > environment variable.
> 
> It seems odd that for any project except KDE, you set CMAKE_PREFIX_PATH and
> for KDE you have to set KDEDIRS instead. You're removing and re-adding the
> feature with a different name.

No.
When starting to search for a KDE frameworks library via FindKF5.cmake, it 
will use all the normal cmake search dirs, and additionally KDEDIRS.
The current FindKDE4.cmake which comes with cmake does the same since years 
and it works just fine.

Once it has found a KDE frameworks library, then it will not search in all 
possible directories anymore, but only in the one it found the first library, 
and those in KDEDIRS.
This means to get a mix of KDE frameworks libraries from different 
installations, you have to set up KDEDIRS intentionally in some way.

This would bring basically the same kind of grouping as with the proposed 
extra KF5-cmake package.

> If the shared-install-dirs is removed, is the SHADOWING feature you
> mentioned before needed anymore?

The SHADOWING would work via KDEDIRS.
We can discuss whether for searching the following components maybe 
CMAKE_PREFIX_PATH should still be honoured, and only the default paths should 
be disabled. But I think that's a minor issue. Both are usually set 
explicitely by the user.
 
> > Now that it seems the shared-install-dirs feature can be removed, this
> > could be good enough.
> > It would imply that e-c-m will be updated relatively often
> 
> Why would it need to be updated relatively often? Why does the removal of
> the shared-install-dirs feature imply that?

The removal (or not-even-creation) of a KF5-cmake package implies that.
This would have been the place where KDE-buildsystem stuff would have been 
put, e.g. the list of known libraries which belong to KDE frameworks.
If we don't have such a package, it probably has to be in e-c-m.
 
> > and that the
> > kde-modules/ dir in e-c-m will indeed be quite KDE-ish.
> 
> So, are you dropping the idea of a separate dependency which everything
> depends on?

Yes, what I proposed does not have such a separate dependency, has an almost 
as good grouping, at the cost of bringing more KDE stuff into e-c-m.

Alex