Providing version details in the depName-config-version.cmake file FetchContent writes to CMAKE_FIND_PACKAGE_REDIRECTS_DIR
Background for this proposal: https://discourse.cmake.org/t/fetchcontent-and-project-name-version/7762/4
When FetchContent_MakeAvailable()
is called on a dependency where FIND_PACKAGE_ARGS
or OVERRIDE_FIND_PACKAGE
was included in the keywords to FetchContent_Declare()
, or where FETCHCONTENT_TRY_FIND_PACKAGE_MODE
was set to ALWAYS
when FetchContent_Declare()
was called, then FetchContent_MakeAvailable()
will write a very minimal <depName>-config-version.cmake
file to the CMAKE_FIND_PACKAGE_REDIRECTS_DIR
directory. That file currently only contains the bare minimum needed to ensure a find_package()
call won't reject the associated <depName>-config.cmake
file based on version constraints. It does not currently set PACKAGE_VERSION
, which means the find_package()
caller won't see any <depName>_VERSION*
variables set by the command. However, it may be possible to extract a pretty likely version number from the dependency's top level project()
command in some cases. If the FetchContent_Declare()
caller knows that the dependency's top level project()
command does provide a VERSION
and that version is acceptable for use as the version number of the package, then it could include a new keyword that indicates this. FetchContent_MakeAvailable()
could then extract that version information and include it as part of the <depName>-config-version.cmake
file it writes out.
The version details set by project(SomeProject VERSION ...)
are not visible to the parent scope by default. But FetchContent_MakeAvailable()
could make use of CMAKE_PROJECT_INCLUDE
to call cmake_language(DEFER ... CALL ...)
to write the <depName>-config-version.cmake
file at the end of the dependency's CMakeLists.txt
file while the PROJECT_VERSION*
variables are still in scope. It would only write that file if it didn't already exist, which ensures the dependency still has the ability to write its own such file and have that take priority.