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

Thu May 24 02:45:30 EDT 2018

Den ons 23 maj 2018 17:18Mateusz Loskot <mateusz at loskot.net> skrev:

> 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.
>

As for my part, I'll just have to agree to disagree with this. When I first
learned about CMake many years ago, I always thought it strange that it
came bundled with a bunch of Find modules (compared to say the pkg-config
approach), because it seemed to me such an obviously futile effort to get
coverage/keep them up to date.

Maybe the bundled modules served (and continues to serve) a purpose in that
they encourage the uptake of CMake. But I think CMake has grown so much by
now, and has such leverage (people generally are not opposed to being
"CMake compatible"), that efforts are better spent making it easy to write
config files, and supporting initiatives like that cps thing.

I also don't agree that it doesn't hurt CMake to have a growing number of
outdated find modules. It leads to a lot of bug reports. If it's there,
people will expect it to work, and when it doesn't they become
disappointed. If it wasn't there from the beginning there's no expectation.

My 2 cents

> > 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
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180524/f6fd4a40/attachment.html>