[CMake] Contribute Find-module to CMake vs Config-file to upstream

[Paul Fultz II]

> On May 22, 2018, at 6:36 AM, rleigh at 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