[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