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

Tue May 22 03:26:52 EDT 2018

+1 to the gitlab central repository

On Mon, 21 May 2018 at 19:39, Mateusz Loskot <mateusz at loskot.net> wrote:

> 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
> --
>
> 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/20180522/d80357c1/attachment.html>