The issue with the install dirs...
neundorf at kde.org
Wed Dec 14 17:44:26 UTC 2011
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.
More information about the Kde-buildsystem