[vcpkg-cmake-config] Wrong *Config.cmake files for CMake 3.29.1

[SimiPro]

Describe the bug Suddenly some of the libraries i use: tinyobjloader, tesseract, effolkronium_random have a wrong path in their corresponding *Config.cmake file.

The vcpkg phase works fine and then when I try to do find_package it crashes usually out of the *Config.cmake file from functions such as set_and_check.

Environment

• OS: Linux
• Compiler: revision gcc-11

To Reproduce Steps to reproduce the behavior:

1. ./vcpkg install effolkronium-random ( I used manifest mode)
2. find_package(effolkronium_random CONFIG REQUIRED)
3. see error

You can also checkout this repo: https://github.com/SimiPro/starter-cmake-vcpkg-simple and it crashes when you build the target app1.

But if you comment out the "find_package(effolkronium_random CONFIG REQUIRED)" in the apps/app1/CMakeLists.txt it works.

Expected behavior No error

Failure logs [cmake] CMake Error at out/build/dev-debug-test/vcpkg_installed/x64-linux/share/effolkronium_random/effolkronium_randomConfig.cmake:11 (message): [cmake] File or directory [cmake] /home/simi/projects/starter_cmake_vcpkg/out/build/dev-debug-test/vcpkg_installed/x64-linux/share/include [cmake] referenced by variable EFFOLKRONIUM_RANDOM_INCLUDE_DIR does not exist ! [cmake] Call Stack (most recent call first): [cmake] out/build/dev-debug-test/vcpkg_installed/x64-linux/share/effolkronium_random/effolkronium_randomConfig.cmake:26 (set_and_check) [cmake] out/build/dev-debug-test/_deps/vcpkg-src/scripts/buildsystems/vcpkg.cmake:859 (_find_package) [cmake] libs/lib1/CMakeLists.txt:11 (find_package)

Additional context

I can fix them. Usually the path is one to deep or one to less deep. But obviously after each configure i have to re-fix it.

concrete example would be the path effolkronium_randomConfig.cmake this line: get_filename_component(PACKAGE_${CMAKE_FIND_PACKAGE_NAME}_COUNTER_1 "${CMAKE_CURRENT_LIST_DIR}/../" ABSOLUTE)

Should be: get_filename_component(PACKAGE_${CMAKE_FIND_PACKAGE_NAME}_COUNTER_1 "${CMAKE_CURRENT_LIST_DIR}/../../" ABSOLUTE)

You can also see the error in the github action on the project: https://github.com/SimiPro/starter-cmake-vcpkg-simple/actions/runs/8553715519/job/23437459032

[yhyu13]

Hi,

My vcpkg fork is a bit old 53bef8994c541b6561884a8395ea35715ece75db but having a similar problem just poped out today!

I am having similar problem with vckpkg install opentelementry-cpp on linux-64 with find_package(opentelemetry-cpp CONFIG REQUIRED ). Instead of missing one ../, my case was having one extra ../:

Error

CMake Error at Build/Release/vcpkg_installed/x64-linux/share/absl/abslConfig.cmake:16 (message):
  File or directory
  /home/hangyu5/Documents/Gitrepo-My/HLVM-Engine/Engine/Source/Common/Build/Release/vcpkg_installed/include
  referenced by variable OPENTELEMETRY_CPP_INCLUDE_DIRS does not exist !

Where Build/Release/vcpkg_installed/x64-linux/share/absl/abslConfig.cmake:16 reads as

get_filename_component(PACKAGE_${CMAKE_FIND_PACKAGE_NAME}_COUNTER_1 "${CMAKE_CURRENT_LIST_DIR}/../../../" ABSOLUTE)

but it should be "${CMAKE_CURRENT_LIST_DIR}/../../" ABSOLUTE). The errorneous cmake config has ignored the x64-linux directory

Note, my build directory passed to cmake binary is ./Build/Release. I'm not sure if vcpkg has handled these path correctly.

Thanks!

[m-kuhn]

same with libwebp (used by tiff) since a couple of hours

Building tiff[core,jpeg,lzma,zip]:x64-linux@4.6.0#3...
-- Downloading https://gitlab.com/libtiff/libtiff/-/archive/v4.6.0/libtiff-v4.6.0.tar.gz -> libtiff-libtiff-v4.6.0.tar.gz...
-- Extracting source /home/runner/builddir/_deps/vcpkg-src/downloads/libtiff-libtiff-v4.6.0.tar.gz
-- Applying patch FindCMath.patch
-- Applying patch requires-lerc.patch
-- Using source at /home/runner/builddir/_deps/vcpkg-src/buildtrees/tiff/src/v4.6.0-83f89a977c.clean
-- Found external ninja('1.11.1.git.kitware.jobserver-1').
-- Configuring x64-linux
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:112 (message):
    Command failed: /home/runner/work/_temp/-736618759/ninja-1.11.1.g95dee.kitware.jobserver-1_x86_64-linux-gnu/ninja -v
    Working Directory: /home/runner/builddir/_deps/vcpkg-src/buildtrees/tiff/x64-linux-rel/vcpkg-parallel-configure
    Error code: 1
    See logs for more information:
      /home/runner/builddir/_deps/vcpkg-src/buildtrees/tiff/config-x64-linux-rel-CMakeCache.txt.log
      /home/runner/builddir/_deps/vcpkg-src/buildtrees/tiff/config-x64-linux-out.log
Call Stack (most recent call first):
  /home/runner/builddir/vcpkg_installed/x64-linux/share/vcpkg-cmake/vcpkg_cmake_configure.cmake:252 (vcpkg_execute_required_process)
  ports/tiff/portfile.cmake:33 (vcpkg_cmake_configure)
  scripts/ports.cmake:170 (include)
error: building tiff:x64-linux failed with: BUILD_FAILED
Elapsed time to handle tiff:x64-linux: 2.1 s

CMake Error at /home/runner/builddir/vcpkg_installed/x64-linux/share/WebP/WebPConfig.cmake:15 (message):
  File or directory /home/runner/builddir/vcpkg_installed/include referenced
  by variable WebP_INCLUDE_DIR does not exist !
Call Stack (most recent call first):
  /home/runner/builddir/vcpkg_installed/x64-linux/share/WebP/WebPConfig.cmake:38 (set_and_check)
  /home/runner/builddir/_deps/vcpkg-src/scripts/buildsystems/vcpkg.cmake:859 (_find_package)
  cmake/WebPCodec.cmake:29 (find_package)
  CMakeLists.txt:123 (include)

where WebPConfig.cmake:38 reads

set_and_check(WebP_INCLUDE_DIR "${PACKAGE_${CMAKE_FIND_PACKAGE_NAME}_COUNTER_1}/include")

[dg0yt]

Does CMake 3.29 generate different config files? It smells like vcpkg_cmake_config_fixup no longer correctly handling moving the directory to share.

[m-kuhn]

I discover https://github.com/Kitware/CMake/releases/tag/v3.29.1 was released yesterday

[SimiPro]

Does CMake 3.29 generate different config files? It smells like vcpkg_cmake_config_fixup no longer correctly handling moving the directory to share.

Yea you are absolutely right!

https://github.com/SimiPro/starter-cmake-vcpkg-simple/actions/runs/8558878135/job/23454354767

Fixing the cmake version to ~3.28 we build successfully. I don't remember updating, thanks for the help!

I think we should still keep this issue open to fix it for 3.29 ?

--> EDIT: 3.29.0 as by @m-kuhn also correct.

[m-kuhn]

3.29.0 is also fine, see https://github.com/opengisch/QField/actions/runs/8558906456/job/23454442829?pr=5149

[m-kuhn]

It would be nice to open an upstream issue, but my inexistant knowledge about the construct ${PACKAGE_${CMAKE_FIND_PACKAGE_NAME}_COUNTER_1} doesn't allow me to come up with a wording

[dg0yt]

I don't think it is fair to attribute this to CMake. That tool doesn't do anything wrong this time. (But they really shouldn't change it in patch releases.) It is vcpkg_cmake_config_fixup which promises to be able to move cmake config.

[WangWeiLin-MV]

CMake regression in 3.29.1 at Kitware - CMake - !9390.

[goeiecool9999]

The glslang port is also affected. https://github.com/microsoft/vcpkg/blob/5fa0f075ea51f305b627ecd5e050a363707353ff/ports/glslang/portfile.cmake#L34-L38 It tries to replace ${PACKAGE_PREFIX_DIR}/lib/cmake/glslang/glslang-targets.cmake with ${CMAKE_CURRENT_LIST_DIR}/glslang-targets.cmake but can't because ${PACKAGE_PREFIX_DIR} is now ${PACKAGE_${CMAKE_FIND_PACKAGE_NAME}_COUNTER_1}

[teo-tsirpanis]

Will be fixed by #38078.

Never mind, just saw there was another PR.

[dg0yt]

It would be nice to open an upstream issue, but my inexistant knowledge about the construct ${PACKAGE_${CMAKE_FIND_PACKAGE_NAME}_COUNTER_1} doesn't allow me to come up with a wording

For the record https://gitlab.kitware.com/cmake/cmake/-/issues/25873

[bradking]

CMake 3.29.2 reverts the change.

[m-kuhn]

CMake 3.29.2 reverts the change.

Shall we close or will this be an issue again with 3.30?

[bradking]

I suggest closing this for now. The change will likely not be restored by 3.30 in the same way. CMake Issue 25827 tracks the problem originally motivating the change.

[WangWeiLin-MV]

Since CMake version 3.29.2 reverted these changes in Kitware -CMake - 9420, closed this issue.