The issue with the install dirs...

[Alexander Neundorf]

On Wednesday 14 December 2011, Stephen Kelly wrote:
> David Faure wrote:
> > On Tuesday 13 December 2011 21:23:52 Alexander Neundorf wrote:
> >> Somewhat similar, do we still have the plan to provide like a wrapper
> >> FindKF5.cmake/KF5Config.cmake, which will include all libraries making
> >> up KF5  ?
> >> If so, which library/package should install that ?
> >> Who will install the file which contains the compiler flags we recommend
> >> to use for KDE ?
> >> Maybe the same as the one defining the install dirs ?
> > 
> > Actually, after we make the base modular, nothing prevents us from still
> > providing "easy to use, all in one" solutions, like maybe FindKF5 and a
> > set of easy-to-use install dirs.
> > 
> > All we're trying to achieve is that using that stuff isn't *necessary*,
> > to write a Qt+some_frameworks application.
> > 
> > But for the convenience of all the existing KDE apps we could definitely
> > provide what you suggest, from the still-to-come "tier 4" framework.
> > (the one without a proper name yet :-)
> 
> I fully agree with this. If _set_fancy is primarily for the benefit of KDE
> application developers, then it can be as high up in the framework stack as
> necessary or makes sense.

While it sounds reasonable, this still leaves the question where to put e.g. a 
KF5Defaults.cmake (which is current ECMQtFramework.cmake), or a file 
containing (some of) the macros from KDE4Macros.cmake, like e.g. the helper 
macros for adding tests etc.
Right now ECMQtFramework.cmake is in e-c-m, but I think this is not where it 
belongs. It is more like a "base" KDE frameworks thing, and not something of 
general usefulness for cmake-based projects.
The rest of kdelibs/frameworks depends on this file, so it must be there 
*before* building any frameworks lib, installing it on top of them optionally 
doesn't work for that.

Alex