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

[Mateusz Loskot]

Hi,

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_412640

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.
Then I argued taht Config-files are more complex and I don't feel like
asking projects, which I don't maintain myself, to accept the extra complexity.
Finally, Brad replied that CMake doesn't need LZ4 itself and yet for some
reason is expected to know all about it: versions, headers, libraries, etc.
and that it's not scalable to teach CMake about every project in the world.

This opinion does not surprise me and I understand the rationale.
I argue that CMake does need to know about every project in the world,
or every project that CMake users wish to use, directly or indirectly.
Without the knowledge CMake would simply be useless.

I understand CMake maintainers try to shift the responsibility of recognising
"every project in the world" away from the CMake itself as not scalable.
Good approach to avoid need to scale up the maintenance efforts,
but that is a bad news for CMake users.

As a CMake user, I expect to be able to install CMake and get my dependencies
recognised by CMake as CMake's responsibility
I do not want to care if library A which I depend on is actually
CMake-ignorant or not.
I do not want to learn why library A does not support CMake, as often that is
philosopical reason and asking about it ends up with a rough responses.
(Imagine, there are libraries on GitHub which maintainers do not accept
addition of ***non-intrusive*** single .travis.yml file, because they
don't trust it.)
If a library is strictly GNU Autoconf, I'm on lost position trying to convince
maitnainers to accept CMake stuff and even if they do, they won't be willing to
maintain it - broken Config-files may be deployed with new packages.
That puts users of CMake and such library on lost position:
CMake says no to Find-module, the library does not care either.

As CMake user I don't want to be left to the discretion of package maintainers.
Packages may ignore CMake Config-file existence.
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.

It does not contradict with the recommendation that Config-files
should be preferred.
Once a library that used to be searchable only via Find-module only receives
Config-file, both approaches still can be available, no reason to
remove the Find-module.
The CMake's policy of preferring Config-file can still apply, there is no clash,
it is just users now have choice.
If a Find-module becomes outdated, it doesn't break anything else in CMake
ecosystem but can be spotted and potential contributor may arrive with a fix.

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

If CMake does not care about Find-modules, it should not care or
should care about
them equally - thus presence of such find-modules archive deployed should
not affect the health of CMake installation and its pursue fo
rFind-modules ignorance.

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