ECM install dir (Re: KF5 Update Meeting 2013-w20)

[David Faure]

Le lundi 3 juin 2013 22:24:48 Alexander Neundorf a écrit :
> 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. some of the modules have to be refreshed to be
> > compliant with CMake's standards (coding style, macro usage, variables
> > names,casing...). 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.
> > 
> > - Unless
> > http://mail.kde.org/pipermail/kde-buildsystem/2012-February/008499.html is
> > fixed, I'd also recommend to stay far away from e-c-m.
> 
> this is a problem if a project searches several different versions of e-c-m,
> and the one which is searched first is not the highest required version,
> right ?

No, it's a problem in a much simpler case: your cache in kdelibs points to 
0.0.2, you update ECM, it installs 0.0.3, you update and compile kdelibs, it's 
still pointing to 0.0.2, so it either gives out an error, or never uses the 
0.0.3 stuff.

That's point 1) in the linked email above. Point 2 is indeed about searching 
for several versions in one project, but we can ignore that, as a corner case.

Breaking the `kdesrc-build` workflow (update and recompile everything, without 
deleting all CMakeCache.txt files first) is a major issue IMHO.

> > > I wonder how you plan to handle the conflicts between ECM and kdelibs4's
> > > cmake modules, though...
> 
> Find-modules with the same name ?

Yeah.

> Putting ${ECM_MODULE_PATH} in the first place in CMAKE_MODULE_PATH should
> make cmake prefer the files from there over any others.
> A project can also decide to explicitely use just a subset of the contained
> find-modules:
> 
> ecm_use_find_modules(DIR ${CMAKE_BINARY_DIR}/cmake/ Modules FindBlueZ.cmake
>                      NO_OVERRIDE )
> set(CMAKE_MODULE_PATH ${CMAKE_BINARY_DIR}/cmake/ )
> 
> In which cases should that lead to problems ?

I guess this will work. It just seems like a recipe for trouble, especially 
from people less cmake-knowledgeable than you.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5