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