> On May 22, 2018, at 6:36 AM, rle...@codelibre.net wrote: > > On 2018-05-21 18:39, Mateusz Loskot wrote: >> I've been recently trying to update/add Find-modules to CMake: >> updated FindJPEG, proposed FindODBC and most recently FindLZ4. > […] >> 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. > > It really doesn't scale. I've contributed and provided ongoing fixes for a > few Find modules out of practical necessity, for projects which are > effectively incapable of adding a Config-file, either because the project was > stagnant with no new releases (Xerces, Xalan), or where the project was so > complex that it was effectively impossible to add (Boost). However, that > work should have been done by the upstream. The ongoing maintenance cost has > been moved from the upstream development, where it belongs, to a volunteer > (me). It's work which I do because it provides value to me and my employer > so I can use CMake with the projects I work on, but is otherwise > unjustifiable. You simply can't expect every Find module to keep pace with > upstream development without a small army of volunteers to keep them all up > to date. If they are provided with the upstream releases, they are de facto > always up to date because they are directly matched to the library. > > Note that for several of these projects (e.g. Xerces, libtiff), I have > actually provided upstream CMake build systems which install Config-files, so > in the future the Find modules can be deprecated and users can move to the > Config-file as these releases make their way into distributions. That's > semi-altruistic. I've spent a lot of effort up front to make CMake > infrastructure in these projects maintainable for the long term, and > something which can be delegated to others for ongoing maintenance. > >> 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. > > Not useless, that's going a bit far. It's requiring a little bit of extra > work to be functional. For libraries without Find modules, you can usually > write your own in a couple of dozen lines. At that point your options are: > > - to upstream it as a Config-file template to the upstream developers > - to maintain it independently in your project > - to upstream it to cmake.git > > Depending upon the library in question, I've done all three at various times. > >> As a CMake user, I expect to be able to install CMake and get my dependencies >> recognised by CMake as CMake's responsibility > >> 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. > > If it's using Autoconf, then it can still provide and install CMake > configuration files. It can use @var@ substitutions in the Config-file.in > template and then install it. Just like for pkg-config templates.
If a project already uses pkg-config, a user could just use that for its usage requirements. Even more, why couldn’t cmake support this natively? That is the user can just write something like `find_package(zlib CONF)` to get zlib’s usage requirements. This would simplify when a cmake project wants to generate config cmake which uses a pkg-config file, as we can just write `find_dependency(zlib CONF)`. Paul -- 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
