The issue with the install dirs...

[Stephen Kelly]

Alexander Neundorf wrote:

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

Yes, to some extent that is still an open question.

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

I'd be inclined to disagree in part. It contains things which we consider 
good practice for a framework - setting some strict compiler flags and Qt 
defines, using CMAKE_AUTOMOC, setting CMAKE_LINK_INTERFACE_LIBRARIES empty 
etc.

It's not all perfect of course. It's all exploratory at this point.

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

... but it does work for KDE applications and anything else that depends on 
what is currently called kdelibs. We could consider whether that is relevant 
in all cases.

Thanks,

Steve.