ECM and FindFoo.cmake files

[George Goldberg]

On 5 August 2012 16:08, Alexander Neundorf <neundorf at kde.org> wrote:
> On Sunday 05 August 2012, George Goldberg wrote:
>
>> What is the policy on moving FindFoo.cmake files from frameworks to
>> ECM or upstream. In particular, I have found the following ones still
>> existing in the various tier1 and tier2 migrated frameworks:
>
> Move them one by one to e-c-m when the library in kdelibs/ has been moved to
> tierX/, where it can't/shouldn't use kdelibs/cmake/modules/ anymore.
>
> Here is an overview over Find-files and what should be done with them:
>
> http://community.kde.org/KDE_Core/Platform_11/Buildsystem/FindFilesSurvey
>
> Some changes are listed here:
>
> http://techbase.kde.org/Development/ECM_SourceIncompatChanges
>
> So e.g. we should not use an own copy of FindX11.cmake anymore in KF5, but
> the one which comes with cmake.

Yup I read that page, and get this much.

>> kcoreaddons
>> --FindFAM.cmake
>> kidletime
>> --FindX11.cmake
>> --FindX11XCB.cmake
>> --FindXCB.cmake
>> solid
>> --FindHUPNP.cmake
>> --FindIOKit.cmake
>
> Not sure FindIOKit.cmake is actually needed. Any OSX developers around ?
>
>> --FindMediaPlayerInfo.cmake
>> --FindUDev.cmake
>> kauth
>> --FindPolkitQt-1.cmake
>> --FindPolkitQt.cmake
>>
>> There are various bits of information scattered around the Frameworks
>> wiki suggesting that many (or all?) of these should be upstreamed to
>> either ECM or cmake. Can anyone clarify this a bit as to whether I
>> should try and acheive this or not?
>
> If you are able to upstream some of the files to CMake, great, go for it.
>
> Getting a Find-module into cmake goes together with volunteering to maintain
> it in the forseeable future, i.e. caring about bugs reported against it etc.
> in cmake.

OK makes sense - I'll leave these ones since none of them are specific
to an area I know at all well.

> No KDE repository/project/module except extra-cmake-modules should install
> any Find-modules anymore with KF5.
>
> So either the repositories get their own copies of the files they use, or it
> must be upstreamed somewhere, e-c-m or cmake.

So, getting to the root of it, is one of these two scenarios
preferred? Should all FindFoo macros that are provided with frameworks
be looking to eventually go upstream to cmake or ECM, or is it just
fine to have them in the frameworks themselves?

>
> For e-c-m basically the same compatibility guarantees as for cmake itself
> apply:
>
> http://techbase.kde.org/Policies/CMake_and_Source_Compatibility
>
> http://techbase.kde.org/Policies/CMake_Coding_Style

What about the "maintainership" aspect of upstreaming to cmake? Does
this apply to ECM as well?


--
George