[bug] qt install broken since 2.3.0

[stevenwdv]

Describe the bug

Installing qt doesn't work anymore with Conan 2.3.0, while with 2.2.3 it works fine.

Normally I'd report this with Conan Center, but this is apparently a regression with Conan itself. Although it may still need to be handled at the package level, I don't know.

From my uninformed view, I think that the direct cause may be e11c576.

How to reproduce it

Execute conan install --build=missing --requires=qt/[~6] -c tools.system.package_manager:mode=install -o 'qt/*:with_sqlite3=False' -o 'qt/*:with_pq=False' -o 'qt/*:with_odbc=False' -o 'qt/*:with_brotli=False' -o 'qt/*:with_openal=False' -o 'qt/*:with_md4c=False' -o 'qt/*:with_harfbuzz=False' (extra options added to minimize install time)

Observe error from QtAutoDetectHelpers.cmake:

-------- Installing package qt/6.7.0 (24 of 24) --------
qt/6.7.0: Building from source
qt/6.7.0: Package qt/6.7.0:17bf0d3aab03076f47fb317bf8b4717e53c54c4d
qt/6.7.0: Building your package in /root/.conan2/p/b/qt9828303c46bfb/b
qt/6.7.0: Calling generate()
qt/6.7.0: Generators folder: /root/.conan2/p/b/qt9828303c46bfb/b/build/Release/generators
qt/6.7.0: CMakeDeps necessary find_package() and targets for your CMakeLists.txt
    find_package(OpenSSL)
    find_package(PCRE2)
    find_package(double-conversion)
    find_package(Fontconfig)
    find_package(freetype)
    find_package(ICU)
    find_package(PNG)
    find_package(xkbcommon)
    find_package(ZLIB)
    find_package(xorg)
    find_package(opengl_system)
    target_link_libraries(... openssl::openssl pcre2::pcre2 double-conversion::double-conversion Fontconfig::Fontconfig Freetype::Freetype icu::icu PNG::PNG xkbcommon::xkbcommon ZLIB::ZLIB xorg::xorg opengl::opengl)
qt/6.7.0: WARN: replace_in_file didn't find pattern ' IMPORTED)
' in 'module-Iconv-release-x86_64-data.cmake' file.
qt/6.7.0: WARN: replace_in_file didn't find pattern ' IMPORTED)
' in 'ZLIB-release-x86_64-data.cmake' file.
[...]
qt/6.7.0: CMakeToolchain generated: conan_toolchain.cmake
qt/6.7.0: CMakeToolchain generated: /root/.conan2/p/b/qt9828303c46bfb/b/build/Release/generators/CMakePresets.json
qt/6.7.0: CMakeToolchain generated: /root/.conan2/p/qtbacac31821945/s/src/CMakeUserPresets.json
qt/6.7.0: Generating aggregated env files
qt/6.7.0: Generated aggregated env files: ['conanbuild.sh']
qt/6.7.0: Calling build()
qt/6.7.0: Running CMake.configure()
qt/6.7.0: RUN: cmake -G "Ninja" -DCMAKE_TOOLCHAIN_FILE="generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/root/.conan2/p/b/qt9828303c46bfb/p" -DQT_USE_VCPKG="OFF" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/root/.conan2/p/qtbacac31821945/s/src"
CMake Error at qtbase/cmake/QtAutoDetectHelpers.cmake:127 (file):
  file failed to open for reading (No such file or directory):

    /root/.conan2/p/qtbacac31821945/s/src/generators/conan_toolchain.cmake
Call Stack (most recent call first):
  qtbase/cmake/QtAutoDetectHelpers.cmake:473 (qt_auto_detect_android)
  qtbase/cmake/QtAutoDetect.cmake:5 (qt_internal_setup_autodetect)
  qtbase/cmake/QtBaseTopLevelHelpers.cmake:16 (include)
  CMakeLists.txt:13 (qt_internal_top_level_setup_autodetect)


-- Using Conan toolchain: /root/.conan2/p/b/qt9828303c46bfb/b/build/Release/generators/conan_toolchain.cmake

[p4vook]

Can confirm, this can be quick-fixed by simply touch-ing the reported file.

This is probably an error with relative/absolute paths.

[memsharded]

I am having a look at this. Apparently the Qt CMake files are using the CMAKE_TOOLCHAIN_FILE as a variable, which is not intended behavior, and ignoring the documentation of CMake allows this variable to be a relative path. It could be this needs to be reported to Qt, but I am still having a look for a solution in the recipe if possible.