[CMake] Modern cmake advise for transitive library dependencies
Roger Leigh
rleigh at codelibre.net
Wed Dec 19 11:35:26 EST 2018
On 18/12/2018 20:54, Craig Scott wrote:
>
> Your XConfig.cmake is responsible for also ensuring all targets it
> depends on are defined. This shouldn't be left up to consumers of X. The
> way this is normally done is pretty much as Alan suggests (it's also the
> way I handle cases analogous to yours in our projects at work). There's
> even a find_dependency()
> <https://cmake.org/cmake/help/latest/module/CMakeFindDependencyMacro.html>
> command intended for precisely this situation to make it a little
> easier, although I generally advise against using it for packages that
> support components due to the way a particular optimisation in its
> implementation affects later find_dependency() calls for the same package.
Can't we drop this optimisation and fix find_dependency, making it
properly usable? I've tested a few of the modules using components to
see if they behave correctly with different sets of components, and I've
not yet encountered any problems due to calling multiple times.
In consequence, I wonder if we could simply drop the "optimisation" and
have find_dependency do nothing more than be a thin wrapper around
find_package. This would solve the problems and should not break
backward compatibility.
The only difference would be if the first find_package call succeeds and
subsequent calls fail, which would alter the value of _FOUND. However,
that's likely exactly what one should expect.
Regards,
Roger
More information about the CMake
mailing list