KF5 Update Meeting 2013-w20
neundorf at kde.org
Mon Jun 3 21:13:32 BST 2013
On Monday 03 June 2013, Christophe Giboudeaux wrote:
> On Monday 03 June 2013 12:34:46 David Faure wrote:
> > On Monday 20 May 2013 11:53:18 Alexander Neundorf wrote:
> > > there was a review request for a find-module for libusb1 here a few
> > > days ago, which we have already in e-c-m, but he can't use it because
> > > it is not
> > > released
> > Could we maybe release a first version of ECM with only find modules, and
> > without the frameworks stuff ? Obviously KF5 wouldn't be able to use
> > that, so it would keep depending on ECM-from-git (and we could still
> > change the API for that stuff if needed, which I assume is the reason
> > for Stephen's "no"). But this way, Qt4/KDE4 apps could start using ECM,
> > for shared find modules.
> I see a couple issues:
> - http://community.kde.org/KDE_Core/Platform_11/Buildsystem/FindFilesSurvey
> is far from being done.
It doesn't have to.
It is good enough if it contains a set of files which are in good shape and
Currently there are not too many files contained:
* FindBlueZ.cmake: good, maybe needs ExactCase variable name adjustments
* FindKF5.cmake: no KF5 released yet, so maybe doesn't matter
* FindLibUSB1.cmake: good
* FindQt5Transitional.cmake: I would prefer not to release that to the public
as it is. A compatibility module for porting Qt4 software to Qt5 may be useful
though. But this should then go into cmake.
* FindX11_XCB.cmake: good
* FindXCB.cmake: good
* ECMDBusAddActivationService.cmake: probably good
* ECMMarkAsTest.cmake: somewhat specialized, probably good
* ECMMarkNonGuiExecutable.cmake: IMO only makes sense together with
KDECMakeSettings.cmake, so I would prefer not to ship that one as it is
* ECMOptionalAddSubdirectory.cmake: good
* ECMPrintVariables.cmake: good (I'd prefer to have that in cmake itself, but
it was rejected)
* ECMQt4To5Porting.cmake: don't know. Docs are missing. Does that belong to
* ECMQtFramework.cmake: about to be removed
* ECMSetupVersion.cmake: good
* ECMUseFindModules.cmake: good
* ECMVersion.cmake: about to be removed
* KDEInstallDirs.cmake: almost good. It provides a useful set of install
destination variables, similar to GNUInstallDirs.cmake. Not sure about the
* KDECMakeSettings.cmake: Generally useful. Docs are missing.
* KDECompilerSettings.cmake: IMO generally useful. Docs are missing.
> some of the modules have to be refreshed to be
> compliant with CMake's standards (coding style, macro usage, variables
> The "upstream?" comment is also confusing, ie I have no
> idea what the criteria are before submitted a Findxxx.cmake upstream or
> let it live in ecm.
This is simple.
If somebody volunteers to maintain a module in cmake, it goes into cmake.
More information about the kde-core-devel