<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">Den ons 23 maj 2018 17:18Mateusz Loskot <<a href="mailto:mateusz@loskot.net">mateusz@loskot.net</a>> skrev:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23 May 2018 at 16:37, David Demelier <<a href="mailto:markand@malikania.fr" target="_blank" rel="noreferrer">markand@malikania.fr</a>> wrote:<br>
> On Mon, 2018-05-21 at 19:39 +0200, Mateusz Loskot wrote:<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<br>
>> 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_4" rel="noreferrer noreferrer" target="_blank">https://gitlab.kitware.com/cmake/cmake/merge_requests/2087#note_4</a><br>
>> 12640<br>
>><br>
>> A bit of a extract from the brief discussion [1]:<br>
>><br>
>> The FindLZ4 discussion basically ended with suggestion from Brad<br>
>> that,<br>
>> instead of adding Find-module to CMake, I should approach LZ4 project<br>
>> and add Config-file to the library itself.<br>
><br>
> Yes, that's the way to go.<br>
<br>
I hoped it will draw clear from my earlier thoughts that I consider discussion<br>
*if* CMake should encourage Find-modules as pointless, or at least<br>
off-topic here.<br>
We should be discussing not *if*, but *how* to keep Find-modules,<br>
enourage new ones, fix existing ones and make both Find-modules and<br>
Config-files coexist.<br>
<br>
Hence, I'm not going to address any of your points trying to convince me<br>
to give up my position. If I do, we will be making circles forever.<br>
<br>
>> Packages of libraries which provide CMake and alternative build<br>
>> configurations<br>
>> may not deploy Config-files or Find-modules.<br>
>><br>
>> IMHO, CMake should encourage contributions of new Find-modules.<br>
><br>
> No.<br>
<br>
Yes.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">My 2 cents</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> What if CMake 3.12 has a FindFooBar module shipped in your package<br>
> manager. But upstream decided to break everything? Change component<br>
> name, change library name? We won't have time to inspect all find<br>
> modules and update them *because* upstream decided to change.<br>
<br>
Nothing. That is already the case and nobody expects Find-modules are<br>
100% solid across CMake X versions of libraries it can recognise.<br>
<br>
Find-modules are "guessers" and as such CMake does not give hard promises.<br>
That is already the case. I will repeat the premise points from earlier:<br>
<br>
- Find-modules are very useful "guessers"<br>
- CMake installs Find-modules of good and bad or broken quality (that<br>
is happening today!)<br>
- CMake does not suffer directly from hosting bad quality Find-modules<br>
- CMake should not care if a Find-module becomes outdated as it would<br>
not suffer directly (as per previous points)<br>
<br>
>> I want to contribute Find-module into a **central place** where I can<br>
>> 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<br>
>> between<br>
>> variety of issue trackers, creating new accounts for one time use or<br>
>> even<br>
>> sending patches via e-mails to maitnainers - not everything lives in<br>
>> 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<br>
>> 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 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<br>
>> 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>
> This sounds like more of a reasonable proposal. CMake should by itself<br>
> not propose any Find* package anymore. A user-managed repository where<br>
> everyone could push their module could be a good idea (just like AUR,<br>
> PPA, copr, and such do for distribution packages)<br>
<br>
I'm glad we agree here.<br>
<br>
I'd like to see such bundle of Find-modules always installed by CMake.<br>
I'd like to see it hosted on <a href="http://gitlab.kitware.com" rel="noreferrer noreferrer" target="_blank">gitlab.kitware.com</a><br>
I'd like to stick to some form of community-powered dictatorship to<br>
ensure minimum quality.<br>
If there is not enough community to maintain it and keep modules up to<br>
date that is fine<br>
- single high quality but outdated FindX.cmake is worth a ton more<br>
than dozen shitty FindX.cmake dangling on GitHub.<br>
CMake scripting lazyness should be kapt away from<br>
<a href="http://gitlab.kitware.com/cmake-find-modules" rel="noreferrer noreferrer" target="_blank">gitlab.kitware.com/cmake-find-modules</a>.<br>
<br>
<br>
Best regards,<br>
-- <br>
Mateusz Loskot, <a href="http://mateusz.loskot.net" rel="noreferrer noreferrer" target="_blank">http://mateusz.loskot.net</a><br>
-- <br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer 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 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 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 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 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 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 noreferrer" target="_blank">https://cmake.org/mailman/listinfo/cmake</a><br>
</blockquote></div></div></div>