On Mon, 2018-05-21 at 19:39 +0200, Mateusz Loskot 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_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. It's not the CMake role to add find module for every single library that exist on earth. Packages configuration file are not that hard to write and Find packages are not necessarily easier to write too. You need to create imported target, check versions, check components and such. All of this is managed by configuration files automatically when using appropriate install+export features. > I understand CMake maintainers try to shift the responsibility of > recognising > "every project in the world" away from the CMake itself as not > scalable. If you look at pkg-config from Linux world, when you install pkg-config you just have the tool that inspects .pc files, it does not come with all libraries implemented in the world. That exactly what should happen with CMake too. > 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. Try to convince them to incorporate a patch, or if they won't I usually keep a custom FindModule in my own repo and reuse it if required. > 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. 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. > 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) Regards, -- David -- 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
