+1 to the gitlab central repository On Mon, 21 May 2018 at 19:39, Mateusz Loskot <mate...@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 >
-- 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
