On 23 May 2018 at 16:37, David Demelier <mark...@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. > 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