|author||Joerg Bornemann <firstname.lastname@example.org>||2022-01-11 17:44:10 +0100|
|committer||Joerg Bornemann <email@example.com>||2022-02-15 14:48:20 +0100|
CMake: Introduce QT_ADDITIONAL_HOST_PACKAGES_PREFIX_PATH
When installing conan packages we have one installation prefix per package. When cross-building a conan package, we need to make known those multiple host prefixes to Qt, analogous to QT_ADDITIONAL_PACKAGES_PREFIX_PATH. Pick-to: 6.2 6.3 Fixes: QTBUG-94524 Change-Id: I68cbede350f95266a5fd3559e9b9c214c5858eed Reviewed-by: Alexandru Croitor <firstname.lastname@example.org>
Diffstat (limited to 'cmake/qt.toolchain.cmake.in')
1 files changed, 6 insertions, 1 deletions
diff --git a/cmake/qt.toolchain.cmake.in b/cmake/qt.toolchain.cmake.in
index 23f322824d..1770969dbf 100644
@@ -81,9 +81,14 @@ endif()
# Handle packages located in QT_ADDITIONAL_PACKAGES_PREFIX_PATH when cross-compiling. Needed for
# We prepend to CMAKE_PREFIX_PATH so that a find_package(Qt6Foo) call works, without having to go
-# through the Qt6 umbrella package. The paths must end in lib/cmake to esnsure the package is found.
+# through the Qt6 umbrella package. The paths must end in lib/cmake to ensure the package is found.
# See REROOT_PATH_ISSUE_MARKER.
# We prepend to CMAKE_FIND_ROOT_PATH, due to the bug mentioned at REROOT_PATH_ISSUE_MARKER.
+# Note that we don't handle QT_ADDITIONAL_HOST_PACKAGES_PREFIX_PATH here, because we would thwart
+# our efforts to not accidentally pick up host packages. For now, we say that
+# find_package(Qt6FooTools) is not supported, and people must use find_package(Qt6 COMPONENTS
+# FooTools) instead.