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

[Mateusz Loskot]

On 22 May 2018 at 12:27, Johannes Zarl-Zierl <johannes.zarl-zierl at jku.at> wrote:
> On Montag, 21. Mai 2018 19:39:16 CEST Mateusz Loskot wrote:
>> 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
>
> There's more that we (as CMake community) could do to make it easier for non-
> cmake projects to add a config file, and I think this is a worthwhile goal.
>
> Currently, if the maintainer of an autotools-based project is willing to add a
> cmake config file, he or she basically needs to be an expert on cmake. There's
> no official template or guide on how to create a cmake config file without relying
> on a cmake module to do the work.

Hi Johannes,

I can onl agree.
In fact, I called the Config-files approach complex partially due to lack of
easy to follow tutorial.
Partially due to beign too lazy to figure step-by-step procedure from
https://cmake.org/cmake/help/v3.11/manual/cmake-packages.7.html

> If there was a good guide, or maybe even some tooling, cmake config files would
> not be much more work for the maintainer as pkg-config files.

This should be no-brainer.
This should be no-brainer to such extend that for cases of canonical
configurations
CMake should generate all the required *-{config|version}.cmake
And, the CMake documentation should tell what to do, how to fix my
CMakeLists.txt
to make help CMake generate all the files.

>> I call CMake to accept *any* Find-module, filtering only based on
>> quality of CMake
>> idiomatic scripting.
>
> "Filtering based on quality" being the important part.

Idiomatic quality of CMake scripts is very important.
I've seen enough cases of CMake scripting abuse to finally
strive for some linting reflex and must-obey conentions.

Very recently, I've proposed FindODBC
https://gitlab.kitware.com/cmake/cmake/merge_requests/2069
A trivial script one may think, but look at number of review-refine iterations
it too me to improve it (acceptance is still pending).

Here, I would like to thank Brad King a ton.
He's patience to review, suggest where and how to improve
every tiniest detail is priceless.
Have a look at the discussion comments for the MR 2069,
learning outcome from that MR alone makes a substantial
CMake coding guide to me.
I do realise such help consumes a lot of Brad's time  and
I do realise it might be one of reasons CMake may prefer to
avoid such heavy engagement of maintainers by 'outsource'
libraries look-up responsibility.
But, perhaps an easier solution would be to move things and relax requiremnets.

    Il meglio è nemico del bene

I wish there was an official CMake coding guide.
(I'm hoping to collect my experience based on reviews of my
MR-s to FindJPEG, FindODBC and FindLZ4).

>> 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
>
> That seems like a reasonable way to deal with the situation. Maybe this would
> also encourage better quality of the (current) core find-modules. If you take a
> look at those, they are in wildly different shape regarding their quality.


Yes, I have noticed the low quality modules.
I am taking baby steps to improve them, at least in (library) areas of
my interest.

My initial story started with the simple premise:
- Find-modules are very useful "guessers"
- Find-modules are going to stay as they complement preferred Config-files
- CMake installs selection of Find-modules which should be allowed to expand
- CMake installs Find-modules of good and bad or broken quality
- CMake does not suffer directly from hosting bad quality Find-modules
- CMake should let the community propose and maintain Find-modules
- CMake should not care if a Find-module becomes outdated as it would
not suffer directly (as per previous points)
...


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