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