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).

Alas, 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. :slight_smile:

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. :slight_smile:

But I understand why the practice of adding find modules for everything into CMake proper is unsustainable.

FWIW, cmake/FindZstd.cmake at develop · boostorg/cmake (