<div dir="ltr">+1 to the gitlab central repository<br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 21 May 2018 at 19:39, Mateusz Loskot <<a href="mailto:mateusz@loskot.net">mateusz@loskot.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I've been recently trying to update/add Find-modules to CMake:<br>
updated FindJPEG, proposed FindODBC and most recently FindLZ4.<br>
<br>
Discussion during review of the FindLZ4 [1] ended with some surprising<br>
conclusions which I, as someone who relies on CMake and occacionally<br>
contributes to CMake, don't necessarily agree with.<br>
I'd like to share some of my thoughts.<br>
<br>
[1] <a href="https://gitlab.kitware.com/cmake/cmake/merge_requests/2087#note_412640" rel="noreferrer" target="_blank">https://gitlab.kitware.com/cmake/cmake/merge_requests/2087#note_412640</a><br>
<br>
A bit of a extract from the brief discussion [1]:<br>
<br>
The FindLZ4 discussion basically ended with suggestion from Brad that,<br>
instead of adding Find-module to CMake, I should approach LZ4 project<br>
and add Config-file to the library itself.<br>
Then I argued taht Config-files are more complex and I don't feel like<br>
asking projects, which I don't maintain myself, to accept the extra complexity.<br>
Finally, Brad replied that CMake doesn't need LZ4 itself and yet for some<br>
reason is expected to know all about it: versions, headers, libraries, etc.<br>
and that it's not scalable to teach CMake about every project in the world.<br>
<br>
This opinion does not surprise me and I understand the rationale.<br>
I argue that CMake does need to know about every project in the world,<br>
or every project that CMake users wish to use, directly or indirectly.<br>
Without the knowledge CMake would simply be useless.<br>
<br>
I understand CMake maintainers try to shift the responsibility of recognising<br>
"every project in the world" away from the CMake itself as not scalable.<br>
Good approach to avoid need to scale up the maintenance efforts,<br>
but that is a bad news for CMake users.<br>
<br>
As a CMake user, I expect to be able to install CMake and get my dependencies<br>
recognised by CMake as CMake's responsibility<br>
I do not want to care if library A which I depend on is actually<br>
CMake-ignorant or not.<br>
I do not want to learn why library A does not support CMake, as often that is<br>
philosopical reason and asking about it ends up with a rough responses.<br>
(Imagine, there are libraries on GitHub which maintainers do not accept<br>
addition of ***non-intrusive*** single .travis.yml file, because they<br>
don't trust it.)<br>
If a library is strictly GNU Autoconf, I'm on lost position trying to convince<br>
maitnainers to accept CMake stuff and even if they do, they won't be willing to<br>
maintain it - broken Config-files may be deployed with new packages.<br>
That puts users of CMake and such library on lost position:<br>
CMake says no to Find-module, the library does not care either.<br>
<br>
As CMake user I don't want to be left to the discretion of package maintainers.<br>
Packages may ignore CMake Config-file existence.<br>
Packages of libraries which provide CMake and alternative build configurations<br>
may not deploy Config-files or Find-modules.<br>
<br>
IMHO, CMake should encourage contributions of new Find-modules.<br>
<br>
It does not contradict with the recommendation that Config-files<br>
should be preferred.<br>
Once a library that used to be searchable only via Find-module only receives<br>
Config-file, both approaches still can be available, no reason to<br>
remove the Find-module.<br>
The CMake's policy of preferring Config-file can still apply, there is no clash,<br>
it is just users now have choice.<br>
If a Find-module becomes outdated, it doesn't break anything else in CMake<br>
ecosystem but can be spotted and potential contributor may arrive with a fix.<br>
<br>
I want to contribute Find-module into a **central place** where I can easily<br>
access it as well as monitor its state and submit fixes if necessary.<br>
>From a contributor POV, that is much more effective than jumping between<br>
variety of issue trackers, creating new accounts for one time use or even<br>
sending patches via e-mails to maitnainers - not everything lives in GitHub yet.<br>
<br>
Since CMake is still de-facto a standard for building C++ software,<br>
from end-user POV the current situation feels almost like vendor lock-in.<br>
<br>
I call CMake to accept *any* Find-module, filtering only based on<br>
quality of CMake<br>
idiomatic scripting.<br>
<br>
If CMake does not want Find-* modules within the source tree, then<br>
- set up <a href="https://gitlab.kitware.com/cmake/find-modules" rel="noreferrer" target="_blank">https://gitlab.kitware.com/cmake/find-modules</a><br>
- move all existing Find-modules in there<br>
- relax maintenance rules to accept *any* Find-module, provided<br>
--- CMake scripting is decent quality (e.g no community downvotes or rejecting<br>
     reviews for period of quarantine)<br>
--- CI passing tests<br>
- finally, include the complete find-modules archive in the installer<br>
so it is deployed<br>
   aside of CMake itself<br>
<br>
If CMake does not care about Find-modules, it should not care or<br>
should care about<br>
them equally - thus presence of such find-modules archive deployed should<br>
not affect the health of CMake installation and its pursue fo<br>
rFind-modules ignorance.<br>
<br>
Best regards,<br>
-- <br>
Mateusz Loskot, <a href="http://mateusz.loskot.net" rel="noreferrer" target="_blank">http://mateusz.loskot.net</a><br>
-- <br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://cmake.org/mailman/listinfo/cmake" rel="noreferrer" target="_blank">https://cmake.org/mailman/listinfo/cmake</a><br>
</blockquote></div>