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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
