Zbigniew Jędrzejewski-Szmek wrote:
CMake for many years fought against pkgconf and pushed people
towards
copying those scripts into sources. It is still very common for projects
using CMake to come with a whole directory of badly written detection
scripts that each replace a single-line pkgconf invocation.
Find*.cmake scripts for many common libraries are actually shipped with
CMake itself. More and more libraries even ship their own *Config.cmake
which makes a Find*.cmake script entirely unnecessary.
For less common libraries, you are probably better off simply using the
CMake pkg-config integration, which exists. Assuming of course that that
library ships a .pc file to begin with, otherwise, pkg-config is not going
to help you. (And when I write "pkg-config", I mean either the original pkg-
config or pkgconf, the build system should not need to care about the
difference.)
The reason CMake upstream recommends against using pkg-config directly, and
instead to use it at most as a source of hints for CMake's find_* commands
(e.g., find_library) in a Find*.cmake script, is that using pkg-config on
Windows is often frowned upon. So typically, the way it works is that
someone first writes a Find*.cmake that finds the library in the standard
paths using find_library, then extends it to invoke pkg-config using the
CMake pkg-config integration under "if (UNIX)" and to add the result as a
path hint to the already written find_library call.
And of course nobody has time to look into those scripts, making it
easy to smuggle something through there.
You are right that bundled Find*.cmake scripts are a problem.
Kevin Kofler