Wrong config file being picked up

[brewmook]

Hi,

I'm running into a problem where cmake is finding the debug version of a config file before the non-debug. I've set CMAKE_BUILD_TYPE to Release so that vcpkg doesn't put the debug folder first in CMAKE_PREFIX_PATH, and yet it keeps finding debug first.

Running cmake configure with --debug-find gives me the following (snippets for brevity):

  CMAKE_PREFIX_PATH variable [CMAKE_FIND_USE_CMAKE_PATH].

    D:/project/build/vcpkg_installed/x64-windows
    D:/project/build/vcpkg_installed/x64-windows/debug

<...snip...>

   find_package considered the following locations for the Config module:

    D:/project/build/vcpkg_installed/x64-windows/debug/XYZConfig.cmake
    D:/project/build/vcpkg_installed/x64-windows/debug/xyz-config.cmake
    D:/project/build/vcpkg_installed/x64-windows/debug/lib/cmake/XYZ/XYZConfig.cmake

  The file was found at

    D:/project/build/vcpkg_installed/x64-windows/debug/lib/cmake/XYZ/XYZConfig.cmake

Why is cmake looking in debug first when it's second in the CMAKE_PREFIX_PATH?

Yes, I realise the location of the config is a little odd, but I can't change that (upstream dependency)

Stack traces point to vcpkg/scripts/buildsystems/vcpkg.cmake:859 (_find_package) but I can't find the definition of _find_package in vcpkg, vcpkg-tool or cmake source. Where is it defined?

[dg0yt]

Are you actively avoiding naming a particular vcpkg port and showing the full CMake call stack? Then it might be hard to help.

[brewmook]

Yes, I'm deliberately avoiding the specific package mainly because I didn't think it was relevant. I thought it was either vcpkg or cmake internals that were the problem. Maybe I should have phrased my post differently.

With some more digging I've realised that the underscore on the start of find_package just means "use the original function, avoiding hooks that allow vcpkg to intercept find_package() calls". I thought it was maybe a vcpkg macro or something. It's hard to just google for that.

I've now found the source in cmake, namely Source/cmFindPackageCommand.cxx, so I can at least see what's happening under the hood to make it find the debug file before the non-debug.

The main revelation from this afternoon is that it's broken in cmake 3.22, but working as expected in 3.30. I now just want to hunt down when it got fixed so I have a suitable minimum cmake version.

[dg0yt]

If you do not want others to reproduce it, then why ask at all?
Letting us add blind guesses usually doesn't help resolve the problem, and it may confuse other users which find this via search engines.

[brewmook]

I just thought the point of the discussions pages here was less formal, and naively hoped that someone reading might think "oh, that was an old bug, you need cmake x.y.z". I didn't find any relevant bug reports and didn't want to log one without knowing more.

I would have put specific steps to reproduce together if it had got as far as a bug report.

[dg0yt]

Something like D:/project/build/vcpkg_installed/x64-windows/debug/lib/cmake/XYZ/XYZConfig.cmake shouldn't exist after vcpkg_cmake_config_fixup().

[brewmook]

Thanks for the suggestion, but I tried this and it just caused different problems due to inflexible paths in the debug config file. I'm dealing with an esoteric in-house prebuilt binary wrapped in a port file.

[brewmook]

It seems like the answer is that something got fixed in cmake 3.23.0 (it is still present in 3.22.6), possibly in the work to add CMAKE_IGNORE_PREFIX_PATH.

[brewmook]

Thanks @dg0yt and @Osyotr for your input. The simplest fix is to upgrade cmake to >=3.23.

[Osyotr]

There should be only one config file for both debug and release and it should be in share/<PackageName>. Everything else is not expected to work.
Good news is that vcpkg_cmake_config_fixup does 99-100% of the heavy lifting by a) merging both configs, b) moving it to share if it's not already there (see CONFIG_PATH and PACKAGE_NAME options) and c) fixing prefix.

[brewmook]

Thanks for the input. I tried that and it didn't work out of the box, so I gave up. I may try it again. But really, this reinforces my case for getting the upstream dependency fixed. Debug and release builds of that are built and packaged more-or-less independently, and I'm trying to do the minimum amount of work!

[dg0yt]

In vcpkg, debug and release are also built independently. The point is that exported config from CMake can be merged more or less easily, because there are different file names to deal with generic properties, release properties and debug properties. The properties model is compatible with multi-config usage.

A hand written config can support multi-config usage too.
Example: ports/pdcurses/unofficial-pdcurses-config.cmake

If you don't care about multi-config usage, it is still possible to have inject a switch based on CMAKE_BUILD_TYPE. I don't have an example right now.

[brewmook]

Good to know. Thank you. I will eventually have to come back and do this properly.

[dg0yt]

I suggest you run CMake with --trace-expand, and study the result.

[brewmook]

That's what made me start thinking it was a cmake issue, and why I wanted to know where _find_package was defined:

D:/project/CMakeLists.txt(151):  message(STATUS CMAKE_BUILD_TYPE: Release )
-- CMAKE_BUILD_TYPE: Release
D:/project/CMakeLists.txt(152):  message(STATUS CMAKE_PREFIX_PATH: D:/project/build/vcpkg_installed/x64-windows;D:/project/build/vcpkg_installed/x64-windows/debug )
-- CMAKE_PREFIX_PATH: D:/project/build/vcpkg_installed/x64-windows;D:/project/build/vcpkg_installed/x64-windows/debug
D:/project/CMakeLists.txt(155):  set(CMAKE_FIND_DEBUG_MODE TRUE )
D:/project/CMakeLists.txt(156):  find_package(XYZ REQUIRED )
D:/project/vcpkg/scripts/buildsystems/vcpkg.cmake(774):  if(VCPKG_TRACE_FIND_PACKAGE )
D:/project/vcpkg/scripts/buildsystems/vcpkg.cmake(782):  math(EXPR z_vcpkg_find_package_backup_id 0 + 1 )
D:/project/vcpkg/scripts/buildsystems/vcpkg.cmake(783):  set(z_vcpkg_find_package_package_name XYZ )
D:/project/vcpkg/scripts/buildsystems/vcpkg.cmake(784):  set(z_vcpkg_find_package_1_ARGN REQUIRED )
D:/project/vcpkg/scripts/buildsystems/vcpkg.cmake(785):  set(z_vcpkg_find_package_1_backup_vars  )
D:/project/vcpkg/scripts/buildsystems/vcpkg.cmake(791):  if(CMAKE_SYSTEM_NAME STREQUAL iOS )
D:/project/vcpkg/scripts/buildsystems/vcpkg.cmake(799):  string(TOLOWER XYZ z_vcpkg_find_package_lowercase_package_name )
D:/project/vcpkg/scripts/buildsystems/vcpkg.cmake(800):  set(z_vcpkg_find_package_vcpkg_cmake_wrapper_path D:/project/build/vcpkg_installed/x64-windows/share/xyz/vcpkg-cmake-wrapper.cmake )
D:/project/vcpkg/scripts/buildsystems/vcpkg.cmake(802):  if(EXISTS D:/project/build/vcpkg_installed/x64-windows/share/xyz/vcpkg-cmake-wrapper.cmake )
D:/project/CMakeLists.txt(815):  elseif(z_vcpkg_find_package_package_name STREQUAL Boost AND EXISTS D:/project/build/vcpkg_installed/x64-windows/include/boost )
D:/project/CMakeLists.txt(829):  elseif(z_vcpkg_find_package_package_name STREQUAL ICU AND EXISTS D:/project/build/vcpkg_installed/x64-windows/include/unicode/utf.h )
D:/project/CMakeLists.txt(836):  elseif(z_vcpkg_find_package_package_name STREQUAL GSL AND EXISTS D:/project/build/vcpkg_installed/x64-windows/include/gsl )
D:/project/CMakeLists.txt(848):  elseif(XYZ STREQUAL CURL AND EXISTS D:/project/build/vcpkg_installed/x64-windows/include/curl )
D:/project/CMakeLists.txt(857):  elseif(xyz STREQUAL grpc AND EXISTS D:/project/build/vcpkg_installed/x64-windows/share/grpc )
D:/project/CMakeLists.txt(859):  else()
D:/project/vcpkg/scripts/buildsystems/vcpkg.cmake(859):  _find_package(XYZ REQUIRED )
D:/project/build/vcpkg_installed/x64-windows/debug/lib/cmake/XYZ/XYZConfigVersion.cmake(1):  set(PACKAGE_VERSION 1.2.3 )

CMake 3.22 hits _find_package() with CMAKE_PREFIX_PATH configured to look in non-debug first, but comes out the other side immediately looking at debug instead.

With 3.23 and up the output is the same until the first line after _find_package where it's reading the non-debug version, as I would have expected:

D:/project/build/vcpkg_installed/x64-windows/lib/cmake/XYZ/XYZConfigVersion.cmake(1):  set(PACKAGE_VERSION 1.2.3 )