We use FetchContent_MakeAvailable to include our own sub-libraries from different repos in the build. The user specifies these sub-libraries through a configure script which drives CMake. The CMake files of these sub-libraries use regular find_package() calls to find each other. To have these find_package() calls being fullfilled with a FetchContent_MakeAvailable() call I am using OVERRIDE_FIND_PACKAGE in combination with FetchContent_Declare(). The developer will work on these sub-library repos from the super build, so we also specify FETCHCONTENT_SOURCE_DIR_<package> to tell CMake we will manage these source directories ourselves.
We need to verify that these fetched sub-libraries meet certain version requirements; the developer may have invoked the configure script in a wrong way, or the self-managed source directories have gone out of sync after the last CMake run.
My idea would be to override the ‘-config-version.cmake’ file in ${CMAKE_FIND_PACKAGE_REDIRECTS_DIR} with the package version config file, but I found in ‘Practical CMake’ that such a file would need to honor certain requirements to explicitly disable these version requirements (section 30.4.3, redirections directory). Is it such a strange use case to want to have a version check on dependencies being fulfilled in this way? Am I approaching this problem in the wrong way?
If you are using FetchContent to provide a dependency, then any version specification in a find_package() call for it is basically meaningless. FetchContent assumes the details you provide are the thing you want to use. This extends to its integration with find_package(), where you’re basically saying “I’m providing dependency X with precise details I give in FetchContent_Declare() or via the FETCHCONTENT_SOURCE_DIR_X variable, so force find_package(X ...) to use that regardless of whatever version or component details it specified”. Put another way, when you provide a dependency via FetchContent, it is your responsibility to ensure the dependency is compatible with the project you are adding it to.
I wouldn’t focus on trying to engineer a <depName>-config-version.cmake file to try to enforce version constraints. The files created in CMAKE_FIND_PACKAGE_REDIRECTS_DIR are not expected to ever fail, meaning they should always result in that package being found successfully. Instead, I’d focus on ensuring the script you are using to drive the whole arrangement is robust. For that, using FETCHCONTENT_SOURCE_DIR_<depName> would normally be something I’d leave alone for the developer to use as a local, temporary override. I suspect you could achieve something more flexible and idiomatic by having a *.cmake script that contains FetchContent_Declare() calls which don’t list a download method and only provide a SOURCE_DIR instead (OVERRIDE_FIND_PACKAGE probably also). You could inject that *.cmake file either by loading it directly from the project, if that makes sense, or letting the developer inject it via CMAKE_PROJECT_TOP_LEVEL_INCLUDES or some other equivalent mechanism.