The issue with the install dirs...

[Alexander Neundorf]

On Thursday 15 December 2011, Stephen Kelly wrote:
> 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.

These are things which every "independent" project should decide for itself.
It starts with the name of the build types, and which flags we add.
E.g. "-Wno-long-long -std=iso9899:1990 -Wundef -Wcast-align".
This is very special, it is ok for KDE apps to use, everybody else will just 
wonder why we set so many flags.

This is stuff agreed upon by KDE developers, while other developers may have 
perfectly valid reasons to use other flags, other buildtypes, other settings, 
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. 

Yes.
But with kdelibs being split into multiple repositories, I think we shouldn't 
copy the code e.g. for the different flags, compilers and build types for each 
one.
There should be one copy they all use.
Maybe this could be an optional file, so the frameworks also build without the 
file, but better if it is available.

Something like
include(KF5Defaults OPTIONAL)
...which would work for setting (or not) the compiler flags, but not e.g. for 
the install dirs or settings like CMAKE_AUTOMOC.

Alex