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. _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
