[CMake] Contribute Find-module to CMake vs Config-file to upstream

[Mateusz Loskot]

On 23 May 2018 at 16:37, David Demelier <markand at malikania.fr> wrote:
> On Mon, 2018-05-21 at 19:39 +0200, Mateusz Loskot wrote:
>>
>> I've been recently trying to update/add Find-modules to CMake:
>> updated FindJPEG, proposed FindODBC and most recently FindLZ4.
>>
>> Discussion during review of the FindLZ4 [1] ended with some
>> surprising
>> conclusions which I, as someone who relies on CMake and occacionally
>> contributes to CMake, don't necessarily agree with.
>> I'd like to share some of my thoughts.
>>
>> [1] https://gitlab.kitware.com/cmake/cmake/merge_requests/2087#note_4
>> 12640
>>
>> A bit of a extract from the brief discussion [1]:
>>
>> The FindLZ4 discussion basically ended with suggestion from Brad
>> that,
>> instead of adding Find-module to CMake, I should approach LZ4 project
>> and add Config-file to the library itself.
>
> Yes, that's the way to go.

I hoped it will draw clear from my earlier thoughts that I consider discussion
*if* CMake should encourage Find-modules as pointless, or at least
off-topic here.
We should be discussing not *if*, but *how* to keep Find-modules,
enourage new ones, fix existing ones and make both Find-modules and
Config-files coexist.

Hence, I'm not going to address any of your points trying to convince me
to give up my position. If I do, we will be making circles forever.

>> Packages of libraries which provide CMake and alternative build
>> configurations
>> may not deploy Config-files or Find-modules.
>>
>> IMHO, CMake should encourage contributions of new Find-modules.
>
> No.

Yes.

> What if CMake 3.12 has a FindFooBar module shipped in your package
> manager. But upstream decided to break everything? Change component
> name, change library name? We won't have time to inspect all find
> modules and update them *because* upstream decided to change.

Nothing. That is already the case and nobody expects Find-modules are
100% solid across CMake X versions of libraries it can recognise.

Find-modules are "guessers" and as such CMake does not give hard promises.
That is already the case. I will repeat the premise points from earlier:

- Find-modules are very useful "guessers"
- CMake installs Find-modules of good and bad or broken quality (that
is happening today!)
- CMake does not suffer directly from hosting bad quality Find-modules
- CMake should not care if a Find-module becomes outdated as it would
not suffer directly (as per previous points)

>> I want to contribute Find-module into a **central place** where I can
>> easily
>> access it as well as monitor its state and submit fixes if necessary.
>> From a contributor POV, that is much more effective than jumping
>> between
>> variety of issue trackers, creating new accounts for one time use or
>> even
>> sending patches via e-mails to maitnainers - not everything lives in
>> GitHub yet.
>>
>> Since CMake is still de-facto a standard for building C++ software,
>> from end-user POV the current situation feels almost like vendor
>> lock-in.
>>
>> I call CMake to accept *any* Find-module, filtering only based on
>> quality of CMake
>> idiomatic scripting.
>>
>> If CMake does not want Find-* modules within the source tree, then
>> - set up https://gitlab.kitware.com/cmake/find-modules
>> - move all existing Find-modules in there
>> - relax maintenance rules to accept *any* Find-module, provided
>> --- CMake scripting is decent quality (e.g no community downvotes or
>> rejecting
>>      reviews for period of quarantine)
>> --- CI passing tests
>> - finally, include the complete find-modules archive in the installer
>> so it is deployed
>>    aside of CMake itself
>
> This sounds like more of a reasonable proposal. CMake should by itself
> not propose any Find* package anymore. A user-managed repository where
> everyone could push their module could be a good idea (just like AUR,
> PPA, copr, and such do for distribution packages)

I'm glad we agree here.

I'd like to see such bundle of Find-modules always installed by CMake.
I'd like to see it hosted on gitlab.kitware.com
I'd like to stick to some form of community-powered dictatorship to
ensure minimum quality.
If there is not enough community to maintain it and keep modules up to
date that is fine
- single high quality but outdated FindX.cmake is worth a ton more
than dozen shitty FindX.cmake dangling on GitHub.
CMake scripting lazyness should be kapt away from
gitlab.kitware.com/cmake-find-modules.


Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net