Are there plans to add FindZSTD to CMake, or if not (I understand adding find modules is discouraged), what is the recommended idiomatic way to find zstd? Does every project need to carry its own FindZSTD.cmake, are distributions expected to ship a config file for zstd, or something else? (E.g. pkgconfig.)
Ideally, upstream would provide
-config.cmake files. Barring that,
.pc files makes it easy to use
FindPkgConfig and its APIs. For Windows…I guess folks are left with
FindZSTD.cmake though (since
.pc files aren’t really a thing).
zstd is one of those projects with umpteen build systems that probably differ in subtle and annoying ways. I would really suggest that upstream provide manual
-config.cmake files and
.pc files through every build system (that isn’t vendored at least).
Usually, zstd is made available by the distro package manager, e.g. Ubuntu – File list of package libzstd-dev/bionic/amd64. But there’s no config file there, and suggesting that “upstream” should provide it doesn’t really help people who want to use it.
For such “ubiquitous” libraries, I suspect that find modules still remain the best approach.
I hesitate to express this opinion, but hopefully it will be taken in the right spirit.
Putting such find modules in CMake itself places the burden of ongoing maintenance on CMake too. Experience has shown that these modules are typically not well maintained over time. They are much better off being part of the third party package they are associated with (i.e. Ben’s comments about upstream). That way, the contents are always exactly in sync with the packages for that project.
For those cases where the third party doesn’t want to add that support (CMake config files), putting a find module for them in CMake itself shouldn’t be seen as the fallback. Instead, projects can carry their own find modules and the associated maintenance burden themselves. If it is a popular package, there’s nothing stopping a group of like-minded people or organisations from setting up a dedicated repo on GitHub or similar to host a set of find modules for popular packages that don’t provide their own config files. The maintenance burden can be shared across the community of interested users and contributions would not be tied to CMake’s release cycle. That would require one or more people to agree to set up and more importantly, to maintain such a project, approve submissions, etc.
While I understand the desire to offload the responsibility onto CMake and its contributors, we need to learn from our history here.
I wouldn’t call that “desire to offload responsibility.” It’s not hard to find some FindZstd.cmake in another project and lift it, but, even if we ignore the license issues, all such modules are incomplete or broken in various ways, including the “official” one in facebook/folly. Having the canonical one in CMake avoids duplication, avoids license issues, and can generally be relied upon to be less broken than the alternatives floating around.
But I understand why the practice of adding find modules for everything into CMake proper is unsustainable.
I thought I’d just write a find module and forget about this issue, but unfortunately it turned out to not be so simple. While vendoring a
FindZstd.cmake solves the problem with finding Zstd at build time, after the library using Zstd is installed (along with its CMake config), and then the user tries to
find_package it, the config does
find_dependency(Zstd), which fails, because the find module isn’t there.
How do people solve these issues, apart from getting their find modules shipped with CMake, or somehow getting all distros to ship a config for Zstd? Is there some recommended approach to do this “properly”?
If your project uses its own FindXXX.cmake modules, those will typically need to be installed as part of your project and you add the directory you install them into to the
CMAKE_MODULE_PATH (you do that in your own project’s YYYConfig.cmake file just before you call
find_package() for the XXX dependency).
See this thread: