WebPConfig.cmake is not provided by this package, which seems to cause dependent projects to fail to find libwebp unless they include their own logic
Probably those projects should include their own logic anyways, then (it is as simple as using both pkg_check_modules and find_package and using the first one that succeeds), as it's hardly guaranteed that any given distributor will happen to use cmake. In fact, probably as a general rule of thumb projects depending on libwebp should use pkg_check_modules on linux and find_package on Windows.
Hello Eli, As of now, >=media-libs/openimageio-3 can't be built with WebP support due to lack of WebPConfig.cmake. Before v3 there was the FindWebP.cmake module which was deleted in this PR: https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4354 > Probably those projects should include their own logic anyways So they did the opposite.
Hi, I'm the project lead for OpenImageIO. Modern cmake guidance is is to get rid of the per-project FindFoo.cmake modules (which are idiomatic to the CMake 2.x era) for any dependencies which themselves have modern (3.x era) cmake build systems that export cmake configs for downstream dependencies to consume (those are the WebPConfig.cmake style files). The general philosophy currently is that a package should be responsible for exporting all the right things for downstream consumption because they know how to do it right, rather than EVERY downstream consumer project separately having the burden of hacking up their own FindFoo module and hoping they get it right and don't fall out of sync with the upstream project. So once we raised our minimum supported WebP version high enough that we could count on WebP providing its exported config, we removed our own FindWebP.cmake substitute. That WebPConfig.cmake is built by webp itself and should be part of the package installation in any distro that provides webp. Is there a reason why it's somehow being dropped on the floor by Gentoo? OpenImageIO has lots of other dependencies for which we rely on the exported configs, so if webp is the only dependency having this problem, it can't be that your policy is to never install them. It must be something particular to your webp build and packaging, right?
(In reply to Larry Gritz from comment #3) Hello Larry, Thank you for the quick response! > Is there a reason why it's somehow being dropped on the floor by Gentoo? libwebp supports multiple build systems [1]. Gentoo uses [2] autotools [3] to build it. It looks like libwebp generates CMake configuration only if you use CMake to build it. [1]: https://chromium.googlesource.com/webm/libwebp#building [2]: https://gitweb.gentoo.org/repo/gentoo.git/tree/media-libs/libwebp/libwebp-1.5.0.ebuild#n6 [3]: https://devmanual.gentoo.org/eclass-reference/autotools.eclass/
(In reply to Larry Gritz from comment #3) > Hi, I'm the project lead for OpenImageIO. > > Modern cmake guidance is is to get rid of the per-project FindFoo.cmake > modules (which are idiomatic to the CMake 2.x era) for any dependencies > which themselves have modern (3.x era) cmake build systems that export cmake > configs for downstream dependencies to consume (those are the > WebPConfig.cmake style files). What about modern build systems that export *.pc files for FindPkgConfig.cmake (shipped in CMake's core)? > The general philosophy currently is that a package should be responsible for > exporting all the right things for downstream consumption because they know > how to do it right, rather than EVERY downstream consumer project separately > having the burden of hacking up their own FindFoo module and hoping they get > it right and don't fall out of sync with the upstream project. I agree -- but as a user of non-cmake build systems (usually Meson), it's impractical to produce exported cmake configs. Furthermore, cmake configs can only be used from cmake, not from other build systems. That's precisely why "the Unix standard" is pkg-config, a declarative syntax for dependency exports used and usable by any build system, or even a plain Makefile. > That WebPConfig.cmake is built by webp itself and should be part of the > package installation in any distro that provides webp. Is there a reason why > it's somehow being dropped on the floor by Gentoo? > > OpenImageIO has lots of other dependencies for which we rely on the exported > configs, so if webp is the only dependency having this problem, it can't be > that your policy is to never install them. It must be something particular > to your webp build and packaging, right? As noted, it will be a general issue with any project that supports multiple build systems. For example, see bug 951525 and bug 951524 for two packages that used to build with cmake, but switched back to autotools because they were dependencies of cmake -- and therefore caused bootstrap failures. Since only cmake can export cmake configs, it is necessary to handle the FindPkgConfig route as well. It's quite simple: pkg_check_modules(WEBP IMPORTED_TARGET GLOBAL libwebp) Produces PkgConfig::WEBP that should be precisely equivalent to WebP::webp (and you can alias it if you like).
By the way -- the Meson Build System has a rather elaborate mechanism for handling this. webp_dep = dependency('libwebp', 'WebP', modules: ['WebP::webp']) Will attempt to find each name in turn using a variety of methods. One of those methods is to check using pkg-config. It can also attempt to check if cmake is installed, write out a small CMakeLists.txt that depends on WebP, and configure cmake, then parse the debug logs (in json) that cmake produce, to check for the dependency variables that cmake may have set. There's some logic for guessing if only one imported target is found, and using that automatically. Ideally both cmake and pkg-config use the same name -- but libwebp doesn't provide a find_package(libwebp), they changed the name. :( So, Meson supports listing multiple names in a single dependency lookup and treating them all as candidates. This does mean that projects written on Linux where the pkg-config name works, don't run out of the box on Windows -- and vice versa. So it really is best to use the same name for both, as it means things tend to work out of the box more often.
I agree with Eli's assessment. On Linux pkg-config is the most reliable way to query dependency information; it's supported by CMake and is the standard for Linux dependency resolution. This should be a straightforward change to implement downstream. As identified by Aliaksei, the reason the CMake file support is "dropped on the floor" is that the upstream project supports Autotools and CMake builds, but only generates the CMake files if you use CMake to build the software. We do not, though I haven't taken a look to investigate whether there's a specific reason for this or if the original contributor simply preferred autotools (it may also predate CMake support upstream). It does appear that the CMake build generates pkg-config files, so the inverse issue does not exist. While we could ask upstream to try and generate CMake files in the Autotools build, the more reliable solution is to just use pkg-config, which is what I'm recommending you do. If upstream do make changes to the Autotools build I'm happy to backport them. As a best practice, it's generally better to rely on pkg-config when it's available, as it avoids making the build process dependent on the specific build system used by its dependencies.
