find_package(): Files treated as extra directories to search
Consider the following minimal CMakeLists.txt
:
cmake_minimum_required(VERSION 3.5)
project(findpkg LANGUAGES NONE)
set(CMAKE_PREFIX_PATH ${CMAKE_CURRENT_LIST_DIR}/CheckDir)
set(CMAKE_FIND_DEBUG_MODE TRUE)
find_package(FooBar 1.2 CONFIG
NO_PACKAGE_ROOT_PATH
NO_CMAKE_ENVIRONMENT_PATH
NO_SYSTEM_ENVIRONMENT_PATH
NO_CMAKE_PACKAGE_REGISTRY
NO_CMAKE_SYSTEM_PATH
NO_CMAKE_SYSTEM_PACKAGE_REGISTRY
NO_CMAKE_FIND_ROOT_PATH
)
In the CheckDir
subdirectory, there are the following two files:
FooBarConfig.cmake
FooBarConfigVersion.cmake
I don't think the contents of these files are actually all that important. In my testing, they are just printing things, so they won't result in a successful find. If you now run cmake
, you will see output like the following (this is on macOS):
CMake Debug Log at CMakeLists.txt:7 (find_package):
CMAKE_PREFIX_PATH variable [CMAKE_FIND_USE_CMAKE_PATH].
/Users/craig/Projects/findpkg/CheckDir
CMAKE_FRAMEWORK_PATH and CMAKE_APPBUNDLE_PATH variables
[CMAKE_FIND_USE_CMAKE_PATH].
Paths specified by the find_package HINTS option.
none
Paths specified by the find_package PATHS option.
none
find_package considered the following locations for the Config module:
/Users/craig/Projects/findpkg/CheckDir/FooBarConfig.cmake
/Users/craig/Projects/findpkg/CheckDir/foobar-config.cmake
/Users/craig/Projects/findpkg/CheckDir/FooBarConfig.cmake/FooBarConfig.cmake
/Users/craig/Projects/findpkg/CheckDir/FooBarConfig.cmake/foobar-config.cmake
/Users/craig/Projects/findpkg/CheckDir/FooBarConfigVersion.cmake/FooBarConfig.cmake
/Users/craig/Projects/findpkg/CheckDir/FooBarConfigVersion.cmake/foobar-config.cmake
The file was not found.
Note how FooBarConfigVersion.cmake
and FooBarConfig.cmake
are used as subdirectories in which to search for the config files. These technically match the <prefix>/<name>*/
case in the documented places that find_package()
will search, but there should be a check that these matches are actually directories before treating them as such.
This behavior seems to be present back at least as far as CMake 3.10, but has likely always been present.