AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
3892e86d6e
qt5base-lts/cmake/QtConfig.cmake.in

263 lines
12 KiB
CMake
Raw Normal View History

Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
@PACKAGE_INIT@
CMake: Enable NEW policies by CMake version with a global default When a CMake release introduces a new policy that affects most Qt modules, it may be appropriate to make each module aware of that newer CMake version and use the NEW policy without raising the minimum CMake version requirement. To reduce the churn associated with making that change across all Qt modules individually, this change allows it to be updated in a central place (qtbase), but in a way that allows a Qt module to override it in its own .cmake.conf file if required (e.g. to address the issues identified by policy warnings at a later time). The policies are modified at the start of the call to qt_build_repo_begin(). For commands defined by the qtbase module, qtbase needs to be in control of the policy settings at the point where those commands are defined. The above mechanism should not affect the policy settings for these commands, so the various *Config.cmake.in files must not specify policy ranges in a way that a Qt module's .cmake.conf file could influence. Starting with CMake 3.12, policies can be specified as a version range with the cmake_minimum_required() and cmake_policy() commands. All policies introduced in CMake versions up to the upper limit of that range will be set to NEW. The actual version of CMake being used only has to be at least the lower limit of the specified version range. This change uses cmake_minimum_required() rather than cmake_policy() due to the latter not halting further processing upon failure. See the following: https://gitlab.kitware.com/cmake/cmake/-/issues/21557 Task-number: QTBUG-88700 Pick-to: 6.0 Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-30 07:46:49 +00:00
cmake_minimum_required(VERSION @min_new_policy_version@...@max_new_policy_version@)
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
CMake: Enforce minimum CMake version in user projects This change introduces new behavior to error out when configuring user projects if the CMake version used is too old for Qt to work with. The main motivator is the requirement of new CMake features to ensure object libraries are placed in the proper place on the link line in static builds. The minimum CMake version is computed based on whether Qt was configured as shared or static libraries. At the moment the required versions for building and using Qt are the same. The minimum versions are defined in qtbase/.cmake.conf in the following variables QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_SHARED QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_STATIC QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_SHARED QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_STATIC Qt Packagers can disable the version check when configuring Qt by setting QT_FORCE_MIN_CMAKE_VERSION_FOR_BUILDING_QT and QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT. In this case it is the packagers responsibility to ensure such a Qt works correctly with the specified CMake version. User projects can also set QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT to disable the version check. Then it's the project's developer responsibility to ensure such a Qt works correctly. No official support is provided for these cases. Implementation notes. The versions required to build Qt are stored in QtBuildInternalsExtra.cmake whereas the versions required to use Qt are stored in a new QtConfigExtras.cmake. Also the policy range variables stored in QtBuildInternalsExtra.cmake are now regular variables instead of cache variables, to properly allow overrides per-repository. Some renaming of functions and variables was done for a bit more clarity and easier grep-ability. Pick-to: 6.2 Task-number: QTBUG-95018 Change-Id: I4279f2e10b6d3977319237ba21e2f4ed676aa48b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-22 14:23:51 +00:00
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@ConfigExtras.cmake")
include("${CMAKE_CURRENT_LIST_DIR}/QtPublicCMakeVersionHelpers.cmake")
__qt_internal_require_suitable_cmake_version_for_using_qt()
cmake: Make find_package(Qt5 ...) work properly Introduce a new cached variable INSTALL_CMAKE_NAMESPACE for defining the prefix used for CMake config files (c.f. "${PREFIX}Core/${PREFIX}CoreConfig.cmake") Also make sure to `find_dependency(...)` the required packages inside the individual CMake config files. I.e. in Qt5WidgetsConfig.cmake, search for Qt5Core, etc. pp.. Change-Id: Idc027925fe9d5323091c4853803ad5ce44b1afc6 Reviewed-by: Jean-Michaël Celerier <jean-michael.celerier@kdab.com> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-02-11 10:34:35 +00:00
get_filename_component(_qt_cmake_dir "${CMAKE_CURRENT_LIST_DIR}/.." ABSOLUTE)
Fix examples find_package calls to work in prefix builds To build examples as part of a non-installed Qt prefix build, not-yet-installed Config files need to be found by find_package() calls inside example projects. Facilitate that by propagating the CMAKE_PREFIX_PATH and QT_EXAMPLES_CMAKE_PREFIX_PATH paths in all relevant find_package() calls where NO_DEFAULT_PATH is used. Also adjust the inclusion of the QtFeature.cmake file to be relative to the qt6 directory, rather than the current list directory. This is needed to successfully find the file when parsing a Config file from a non-installed build directory. Change-Id: I36031279628f1f7741d8f4d7571484a6545227f7 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-09-19 11:46:37 +00:00
set(_qt_@PROJECT_VERSION_MAJOR@_config_cmake_dir "${CMAKE_CURRENT_LIST_DIR}")
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
Allow to build examples as standalone project Create CMake config files which can be used from the very same CMake project. These CMake config files simply do not create any targets, controlled via the QT_NO_CREATE_TARGETS. This patch also allows to build qtbase.git:examples as a standalone project, against an already-built Qt. Ran this: ag -s "QT " examples -l -0 | xargs -0 -n 1 .../util/cmake/pro2cmake.py --is-example Task-number: QTBUG-74713 Change-Id: I44cce5a4048618b30f890c5b789592c227a8b47d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-04 15:08:47 +00:00
if (NOT QT_NO_CREATE_TARGETS)
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@Targets.cmake")
CMake: Fix creation of versionless targets for tools We can't use qt_internal_export_modern_cmake_config_targets_file for executables like tools, because it's not possible to use INTERFACE_LINK_LIBRARIES with executables like you can with libraries. We also can't create aliases to non-global imported targets. Instead create new imported executable targets, fish out the imported location, and assign it to the versionless targets. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Task-number: QTBUG-75984 Change-Id: I6a3c9c67ef4699c72a6c9a627c63158dfd6557f8 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-12-05 12:54:07 +00:00
if(NOT QT_NO_CREATE_VERSIONLESS_TARGETS)
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@VersionlessTargets.cmake")
endif()
Allow to build examples as standalone project Create CMake config files which can be used from the very same CMake project. These CMake config files simply do not create any targets, controlled via the QT_NO_CREATE_TARGETS. This patch also allows to build qtbase.git:examples as a standalone project, against an already-built Qt. Ran this: ag -s "QT " examples -l -0 | xargs -0 -n 1 .../util/cmake/pro2cmake.py --is-example Task-number: QTBUG-74713 Change-Id: I44cce5a4048618b30f890c5b789592c227a8b47d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-04 15:08:47 +00:00
else()
# For examples using `find_package(...)` inside their CMakeLists.txt files:
# Make CMake's AUTOGEN detect this Qt version properly
set_directory_properties(PROPERTIES
QT_VERSION_MAJOR @PROJECT_VERSION_MAJOR@
Expose Patch Version in QtConfig.cmake Change-Id: I2166d480c0b717fc9137f8eb42d5aab7a091395d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-12-11 15:14:22 +00:00
QT_VERSION_MINOR @PROJECT_VERSION_MINOR@
QT_VERSION_PATCH @PROJECT_VERSION_PATCH@)
Allow to build examples as standalone project Create CMake config files which can be used from the very same CMake project. These CMake config files simply do not create any targets, controlled via the QT_NO_CREATE_TARGETS. This patch also allows to build qtbase.git:examples as a standalone project, against an already-built Qt. Ran this: ag -s "QT " examples -l -0 | xargs -0 -n 1 .../util/cmake/pro2cmake.py --is-example Task-number: QTBUG-74713 Change-Id: I44cce5a4048618b30f890c5b789592c227a8b47d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-04 15:08:47 +00:00
endif()
cmake: Generate config files with Qt:: prefix Generate CMake config files which export Qt targets with a Qt:: prefix (i.e. without a major version suffix in the namespace) Change-Id: Ia07f98be6d0e24c196e3880b7469f1f0c6232c06 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 10:30:09 +00:00
Always append extra cmake modules to CMAKE_MODULE_PATH in Qt6Config During a static build we need to use the find modules in 3rdparty/extra-cmake-modules/find-modules when generating a ModuleDependencies file, so that the generated find_dependency() calls succeed. This means that the files have to be shipped with Qt6 package, making them pseudo public API. There is also a need to use these files when building QtWayland. Instead of setting / unsetting CMAKE_MODULE_PATH only in module and plugin Dependencies cmake files, just set them once when finding Qt6. This will allow QtWayland and QtX11Extras to easily find the required third party packages, without having to hardcode the paths in multiple repos. Change-Id: I750d0421a269e5632afa1bb62498c2501d73cdb1 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-09-30 11:22:15 +00:00
get_filename_component(_qt_import_prefix "${CMAKE_CURRENT_LIST_FILE}" PATH)
get_filename_component(_qt_import_prefix "${_qt_import_prefix}" REALPATH)
list(APPEND CMAKE_MODULE_PATH "${_qt_import_prefix}")
list(APPEND CMAKE_MODULE_PATH "${_qt_import_prefix}/3rdparty/extra-cmake-modules/find-modules")
list(APPEND CMAKE_MODULE_PATH "${_qt_import_prefix}/3rdparty/kwin")
cmake: Pick up custom Info.plist in user projects We can't rely on the MACOS define as that's set by our private QtPlatformSupport.cmake that's not shipped. Change-Id: I86c578a282a0833408a06d923954510a3579bdaa Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-06-25 15:53:53 +00:00
if(APPLE AND (NOT CMAKE_SYSTEM_NAME OR CMAKE_SYSTEM_NAME STREQUAL "Darwin"))
# Add module directory to pick up custom Info.plist template for macOS
cmake: Add default Info.plist for macOS with some important keys The default Info.plist shipped with CMake lacks an NSPrincipalClass entry, which is crucial for making macOS apps run in full resolution on retina screens. We make sure the file is only picked up on macOS, not iOS and friends, since those platforms require another principal class. If needed we can extract the value out as a CMake variable and use the same file for all Apple platforms. Doing so would assume all keys are single-platform only, so if that's not the case we need platform-specific files. We should probably extract the package type out as a variable too, so that the file can be used for both apps, plugins, and frameworks, but doing so requires setting up that variable somewhere based on the target type, which CMake doesn't allow in an easy way. The file itself is based on the file CMake ships, combined with keys inherited from Qt's existing plist templates for qmake, and adjusted to match what Xcode generates by default these days. Change-Id: I3f5109e5fff63cdbd109a99d4008948d4bd2102b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-11 20:45:50 +00:00
list(APPEND CMAKE_MODULE_PATH "${_qt_import_prefix}/macos")
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
elseif(APPLE AND CMAKE_SYSTEM_NAME STREQUAL "iOS")
# Add module directory to pick up custom Info.plist template for iOS
CMake: Add default launch screen storyboard for iOS apps Bundle a default LaunchScreen.storyboard file for an iOS app and make sure it's referenced in the generated Info.plist file. When launching Qt examples, it ensures the app uses the whole screen space on the device rather than just a square-ish part of it. The storyboard file is a copy of the qmake one, which qmake adds to the Xcode projects it generates. A custom launch screen can be provided either by setting the QT_IOS_LAUNCH_SCREEN variable or by setting the QT_IOS_LAUNCH_SCREEN target property. The value must be an absolute path to the launch screen file. The automatic addition of the launch screen entry in the Info.plist file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN variable to TRUE. The automatic bundling of the launch screen file in the application bundle can be prevented by setting the QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE. The current implementation has a limitation that only one launch screen storyboard and one iOS executable can exist within a project. If there are multiple executables in the project, all of them will use the launch screen that is specified last (the last qt_add_executable call). Because of this limitation, the API is marked as Technical Preview, to be improved upon in the future. For now it simply serves as an improvement to the out-of-the-box experience of iOS apps built with CMake. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Fixes: QTBUG-95837 Change-Id: I6b067d703d635122959a1ef17fcca713da694a86 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-07-15 14:20:20 +00:00
set(__qt_internal_cmake_ios_support_files_path "${_qt_import_prefix}/ios")
list(APPEND CMAKE_MODULE_PATH "${__qt_internal_cmake_ios_support_files_path}")
cmake: Add default Info.plist for macOS with some important keys The default Info.plist shipped with CMake lacks an NSPrincipalClass entry, which is crucial for making macOS apps run in full resolution on retina screens. We make sure the file is only picked up on macOS, not iOS and friends, since those platforms require another principal class. If needed we can extract the value out as a CMake variable and use the same file for all Apple platforms. Doing so would assume all keys are single-platform only, so if that's not the case we need platform-specific files. We should probably extract the package type out as a variable too, so that the file can be used for both apps, plugins, and frameworks, but doing so requires setting up that variable somewhere based on the target type, which CMake doesn't allow in an easy way. The file itself is based on the file CMake ships, combined with keys inherited from Qt's existing plist templates for qmake, and adjusted to match what Xcode generates by default these days. Change-Id: I3f5109e5fff63cdbd109a99d4008948d4bd2102b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-11 20:45:50 +00:00
endif()
CMake: Fix QT_ADDITIONAL_PACKAGES_PREFIX_PATH for cross-builds The QT_ADDITIONAL_PACKAGES_PREFIX_PATH variable was introduced to allow specifying extra locations to find Qt packages. The reason it was introduced instead of just using CMAKE_PREFIX_PATH is because the Qt6 component find_package call uses NO_DEFAULT_PATH which means CMAKE_PREFIX_PATH is ignored. We use NO_DEFAULT_PATH to ensure we don't accidentally pick up system / distro Qt packages. The paths from QT_ADDITIONAL_PACKAGES_PREFIX_PATH are added to the find_package PATHS option in the Qt6 package, each ModuleDependencies.cmake file and some other places. Unfortunately that's not enough to make it work for cross-builds. Imagine the following scenario. host qtbase, qtdeclarative installed in /host_qt target qtbase installed in /target_qtbase target qtdeclarative installed in /target_qtdeclarative We want to cross-build qtlottie. We configure qtlottie as follows /target_qtbase/bin/qt-configure-module /qtlottie_src -- -DQT_ADDITIONAL_PACKAGES_PREFIX_PATH=/target_qtdeclarative We expect the target QtQuick package to be found, but it won't be. The reason is that QT_ADDITIONAL_PACKAGES_PREFIX_PATH is added to the PATHs option, but we don't adjust CMAKE_FIND_ROOT_PATH. Without adding the new paths in CMAKE_FIND_ROOT_PATH, CMake will re-root the passed PATHs under the existing CMAKE_FIND_ROOT_PATH, which is QT_TOOLCHAIN_RELOCATABLE_INSTALL_PREFIX, which evaluates to /target_qtbase. There is no QtQuick package there. To fix this, prepend the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH to CMAKE_FIND_ROOT_PATH. The location where we currently do CMAKE_FIND_ROOT_PATH manipulations is in the qt.toolchain.cmake file, so to be consistent, we prepend the new prefixes there as well. We need to adjust both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH, due the path re-rooting bug in CMake. See https://gitlab.kitware.com/cmake/cmake/-/issues/21937 as well as the existing comment in qt.toolchain.cmake marked with REROOT_PATH_ISSUE_MARKER. We also need to do a few more things to make the setup work Because Qt6Config uses NO_DEFAULT_PATH, the CMAKE_PREFIX_PATH adjustments we do in the toolchain file are not enough, so we still need to add the same prefixes to the Qt6Config find_package PATHS option. One would ask why do we need to adjust CMAKE_PREFIX_PATH at all then. It's for find_package(Qt6Foo) calls to work which don't go through the Qt6Config umbrella package. To make the CMake re-rooting behavior happy, we need to ensure the provided paths are absolute. So we iterate over the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH, to make them absolute. We do the same for the environment variable. We need to append lib/cmake to the prefixes which are added to CMAKE_PREFIX_PATH, otherwise the CMake re-rooting bug is hit. We need to specify the Qt6 package location (${_qt_cmake_dir}) to the PATHS option in the various Dependencies.cmake.in files, to ensure that dependency resolution can jump around between the Qt6 dir and the additional prefixes. Previously the dependency lookup code assumed that all dependencies would be within the same prefix. The same is needed for qt and qml plugin dependency lookup. Amends 7bb91398f25cb2016c0558fd397b376f413e3e96 Amends 60c87c68016c6f02b0eddd4002f75a49ab51d4a8 Amends 5bbd700124d13a292ff8bae6045316112500e230 Pick-to: 6.2 Fixes: QTBUG-95854 Change-Id: I35ae82330fec427d0d38fc9a0542ffafff52556a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 15:03:02 +00:00
set(QT_ADDITIONAL_PACKAGES_PREFIX_PATH "" CACHE STRING
"Additional directories where find(Qt6 ...) components are searched")
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 <alexandru.croitor@qt.io>
2022-01-11 16:44:10 +00:00
set(QT_ADDITIONAL_HOST_PACKAGES_PREFIX_PATH "" CACHE STRING
"Additional directories where find(Qt6 ...) host Qt components are searched")
CMake: Fix QT_ADDITIONAL_PACKAGES_PREFIX_PATH for cross-builds The QT_ADDITIONAL_PACKAGES_PREFIX_PATH variable was introduced to allow specifying extra locations to find Qt packages. The reason it was introduced instead of just using CMAKE_PREFIX_PATH is because the Qt6 component find_package call uses NO_DEFAULT_PATH which means CMAKE_PREFIX_PATH is ignored. We use NO_DEFAULT_PATH to ensure we don't accidentally pick up system / distro Qt packages. The paths from QT_ADDITIONAL_PACKAGES_PREFIX_PATH are added to the find_package PATHS option in the Qt6 package, each ModuleDependencies.cmake file and some other places. Unfortunately that's not enough to make it work for cross-builds. Imagine the following scenario. host qtbase, qtdeclarative installed in /host_qt target qtbase installed in /target_qtbase target qtdeclarative installed in /target_qtdeclarative We want to cross-build qtlottie. We configure qtlottie as follows /target_qtbase/bin/qt-configure-module /qtlottie_src -- -DQT_ADDITIONAL_PACKAGES_PREFIX_PATH=/target_qtdeclarative We expect the target QtQuick package to be found, but it won't be. The reason is that QT_ADDITIONAL_PACKAGES_PREFIX_PATH is added to the PATHs option, but we don't adjust CMAKE_FIND_ROOT_PATH. Without adding the new paths in CMAKE_FIND_ROOT_PATH, CMake will re-root the passed PATHs under the existing CMAKE_FIND_ROOT_PATH, which is QT_TOOLCHAIN_RELOCATABLE_INSTALL_PREFIX, which evaluates to /target_qtbase. There is no QtQuick package there. To fix this, prepend the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH to CMAKE_FIND_ROOT_PATH. The location where we currently do CMAKE_FIND_ROOT_PATH manipulations is in the qt.toolchain.cmake file, so to be consistent, we prepend the new prefixes there as well. We need to adjust both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH, due the path re-rooting bug in CMake. See https://gitlab.kitware.com/cmake/cmake/-/issues/21937 as well as the existing comment in qt.toolchain.cmake marked with REROOT_PATH_ISSUE_MARKER. We also need to do a few more things to make the setup work Because Qt6Config uses NO_DEFAULT_PATH, the CMAKE_PREFIX_PATH adjustments we do in the toolchain file are not enough, so we still need to add the same prefixes to the Qt6Config find_package PATHS option. One would ask why do we need to adjust CMAKE_PREFIX_PATH at all then. It's for find_package(Qt6Foo) calls to work which don't go through the Qt6Config umbrella package. To make the CMake re-rooting behavior happy, we need to ensure the provided paths are absolute. So we iterate over the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH, to make them absolute. We do the same for the environment variable. We need to append lib/cmake to the prefixes which are added to CMAKE_PREFIX_PATH, otherwise the CMake re-rooting bug is hit. We need to specify the Qt6 package location (${_qt_cmake_dir}) to the PATHS option in the various Dependencies.cmake.in files, to ensure that dependency resolution can jump around between the Qt6 dir and the additional prefixes. Previously the dependency lookup code assumed that all dependencies would be within the same prefix. The same is needed for qt and qml plugin dependency lookup. Amends 7bb91398f25cb2016c0558fd397b376f413e3e96 Amends 60c87c68016c6f02b0eddd4002f75a49ab51d4a8 Amends 5bbd700124d13a292ff8bae6045316112500e230 Pick-to: 6.2 Fixes: QTBUG-95854 Change-Id: I35ae82330fec427d0d38fc9a0542ffafff52556a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 15:03:02 +00:00
# Collect additional package prefix paths to look for Qt packages, both from command line and the
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 <alexandru.croitor@qt.io>
2022-01-11 16:44:10 +00:00
# env variable ${prefixes_var}. The result is stored in ${out_var} and is a list of paths ending
# with "/lib/cmake".
function(__qt_internal_collect_additional_prefix_paths out_var prefixes_var)
if(DEFINED "${out_var}")
return()
endif()
set(additional_packages_prefix_paths "")
CMake: Fix QT_ADDITIONAL_PACKAGES_PREFIX_PATH for cross-builds The QT_ADDITIONAL_PACKAGES_PREFIX_PATH variable was introduced to allow specifying extra locations to find Qt packages. The reason it was introduced instead of just using CMAKE_PREFIX_PATH is because the Qt6 component find_package call uses NO_DEFAULT_PATH which means CMAKE_PREFIX_PATH is ignored. We use NO_DEFAULT_PATH to ensure we don't accidentally pick up system / distro Qt packages. The paths from QT_ADDITIONAL_PACKAGES_PREFIX_PATH are added to the find_package PATHS option in the Qt6 package, each ModuleDependencies.cmake file and some other places. Unfortunately that's not enough to make it work for cross-builds. Imagine the following scenario. host qtbase, qtdeclarative installed in /host_qt target qtbase installed in /target_qtbase target qtdeclarative installed in /target_qtdeclarative We want to cross-build qtlottie. We configure qtlottie as follows /target_qtbase/bin/qt-configure-module /qtlottie_src -- -DQT_ADDITIONAL_PACKAGES_PREFIX_PATH=/target_qtdeclarative We expect the target QtQuick package to be found, but it won't be. The reason is that QT_ADDITIONAL_PACKAGES_PREFIX_PATH is added to the PATHs option, but we don't adjust CMAKE_FIND_ROOT_PATH. Without adding the new paths in CMAKE_FIND_ROOT_PATH, CMake will re-root the passed PATHs under the existing CMAKE_FIND_ROOT_PATH, which is QT_TOOLCHAIN_RELOCATABLE_INSTALL_PREFIX, which evaluates to /target_qtbase. There is no QtQuick package there. To fix this, prepend the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH to CMAKE_FIND_ROOT_PATH. The location where we currently do CMAKE_FIND_ROOT_PATH manipulations is in the qt.toolchain.cmake file, so to be consistent, we prepend the new prefixes there as well. We need to adjust both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH, due the path re-rooting bug in CMake. See https://gitlab.kitware.com/cmake/cmake/-/issues/21937 as well as the existing comment in qt.toolchain.cmake marked with REROOT_PATH_ISSUE_MARKER. We also need to do a few more things to make the setup work Because Qt6Config uses NO_DEFAULT_PATH, the CMAKE_PREFIX_PATH adjustments we do in the toolchain file are not enough, so we still need to add the same prefixes to the Qt6Config find_package PATHS option. One would ask why do we need to adjust CMAKE_PREFIX_PATH at all then. It's for find_package(Qt6Foo) calls to work which don't go through the Qt6Config umbrella package. To make the CMake re-rooting behavior happy, we need to ensure the provided paths are absolute. So we iterate over the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH, to make them absolute. We do the same for the environment variable. We need to append lib/cmake to the prefixes which are added to CMAKE_PREFIX_PATH, otherwise the CMake re-rooting bug is hit. We need to specify the Qt6 package location (${_qt_cmake_dir}) to the PATHS option in the various Dependencies.cmake.in files, to ensure that dependency resolution can jump around between the Qt6 dir and the additional prefixes. Previously the dependency lookup code assumed that all dependencies would be within the same prefix. The same is needed for qt and qml plugin dependency lookup. Amends 7bb91398f25cb2016c0558fd397b376f413e3e96 Amends 60c87c68016c6f02b0eddd4002f75a49ab51d4a8 Amends 5bbd700124d13a292ff8bae6045316112500e230 Pick-to: 6.2 Fixes: QTBUG-95854 Change-Id: I35ae82330fec427d0d38fc9a0542ffafff52556a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 15:03:02 +00:00
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 <alexandru.croitor@qt.io>
2022-01-11 16:44:10 +00:00
set(additional_packages_prefixes "")
if(${prefixes_var})
list(APPEND additional_packages_prefixes ${${prefixes_var}})
CMake: Fix QT_ADDITIONAL_PACKAGES_PREFIX_PATH for cross-builds The QT_ADDITIONAL_PACKAGES_PREFIX_PATH variable was introduced to allow specifying extra locations to find Qt packages. The reason it was introduced instead of just using CMAKE_PREFIX_PATH is because the Qt6 component find_package call uses NO_DEFAULT_PATH which means CMAKE_PREFIX_PATH is ignored. We use NO_DEFAULT_PATH to ensure we don't accidentally pick up system / distro Qt packages. The paths from QT_ADDITIONAL_PACKAGES_PREFIX_PATH are added to the find_package PATHS option in the Qt6 package, each ModuleDependencies.cmake file and some other places. Unfortunately that's not enough to make it work for cross-builds. Imagine the following scenario. host qtbase, qtdeclarative installed in /host_qt target qtbase installed in /target_qtbase target qtdeclarative installed in /target_qtdeclarative We want to cross-build qtlottie. We configure qtlottie as follows /target_qtbase/bin/qt-configure-module /qtlottie_src -- -DQT_ADDITIONAL_PACKAGES_PREFIX_PATH=/target_qtdeclarative We expect the target QtQuick package to be found, but it won't be. The reason is that QT_ADDITIONAL_PACKAGES_PREFIX_PATH is added to the PATHs option, but we don't adjust CMAKE_FIND_ROOT_PATH. Without adding the new paths in CMAKE_FIND_ROOT_PATH, CMake will re-root the passed PATHs under the existing CMAKE_FIND_ROOT_PATH, which is QT_TOOLCHAIN_RELOCATABLE_INSTALL_PREFIX, which evaluates to /target_qtbase. There is no QtQuick package there. To fix this, prepend the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH to CMAKE_FIND_ROOT_PATH. The location where we currently do CMAKE_FIND_ROOT_PATH manipulations is in the qt.toolchain.cmake file, so to be consistent, we prepend the new prefixes there as well. We need to adjust both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH, due the path re-rooting bug in CMake. See https://gitlab.kitware.com/cmake/cmake/-/issues/21937 as well as the existing comment in qt.toolchain.cmake marked with REROOT_PATH_ISSUE_MARKER. We also need to do a few more things to make the setup work Because Qt6Config uses NO_DEFAULT_PATH, the CMAKE_PREFIX_PATH adjustments we do in the toolchain file are not enough, so we still need to add the same prefixes to the Qt6Config find_package PATHS option. One would ask why do we need to adjust CMAKE_PREFIX_PATH at all then. It's for find_package(Qt6Foo) calls to work which don't go through the Qt6Config umbrella package. To make the CMake re-rooting behavior happy, we need to ensure the provided paths are absolute. So we iterate over the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH, to make them absolute. We do the same for the environment variable. We need to append lib/cmake to the prefixes which are added to CMAKE_PREFIX_PATH, otherwise the CMake re-rooting bug is hit. We need to specify the Qt6 package location (${_qt_cmake_dir}) to the PATHS option in the various Dependencies.cmake.in files, to ensure that dependency resolution can jump around between the Qt6 dir and the additional prefixes. Previously the dependency lookup code assumed that all dependencies would be within the same prefix. The same is needed for qt and qml plugin dependency lookup. Amends 7bb91398f25cb2016c0558fd397b376f413e3e96 Amends 60c87c68016c6f02b0eddd4002f75a49ab51d4a8 Amends 5bbd700124d13a292ff8bae6045316112500e230 Pick-to: 6.2 Fixes: QTBUG-95854 Change-Id: I35ae82330fec427d0d38fc9a0542ffafff52556a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 15:03:02 +00:00
endif()
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 <alexandru.croitor@qt.io>
2022-01-11 16:44:10 +00:00
if(DEFINED ENV{${prefixes_var}}
AND NOT "$ENV{${prefixes_var}}" STREQUAL "")
Fix QT_ADDITIONAL_(HOST_)PACKAGES_PREFIX_PATH environment variables Except on Windows, the values in CMake environment variables that contain path lists are separated by colons, not semicolons. See documentation of CMAKE_PREFIX_PATH. This is necessary for conan's virtualenv generator which sets these environment variables with native list separators. This amends commit e044c94a61f0cd2bdea1e89be4ec3c68007f7a5c. Pick-to: 6.2 6.3 Task-number: QTBUG-94524 Change-Id: I7f3d140a8462347b181f1d9601fd11cc1ba449db Reviewed-by: Iikka Eklund <iikka.eklund@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-02-22 13:14:26 +00:00
set(prefixes_from_env "$ENV{${prefixes_var}}")
if(NOT CMAKE_HOST_WIN32)
string(REPLACE ":" ";" prefixes_from_env "${prefixes_from_env}")
endif()
list(APPEND additional_packages_prefixes ${prefixes_from_env})
CMake: Fix QT_ADDITIONAL_PACKAGES_PREFIX_PATH for cross-builds The QT_ADDITIONAL_PACKAGES_PREFIX_PATH variable was introduced to allow specifying extra locations to find Qt packages. The reason it was introduced instead of just using CMAKE_PREFIX_PATH is because the Qt6 component find_package call uses NO_DEFAULT_PATH which means CMAKE_PREFIX_PATH is ignored. We use NO_DEFAULT_PATH to ensure we don't accidentally pick up system / distro Qt packages. The paths from QT_ADDITIONAL_PACKAGES_PREFIX_PATH are added to the find_package PATHS option in the Qt6 package, each ModuleDependencies.cmake file and some other places. Unfortunately that's not enough to make it work for cross-builds. Imagine the following scenario. host qtbase, qtdeclarative installed in /host_qt target qtbase installed in /target_qtbase target qtdeclarative installed in /target_qtdeclarative We want to cross-build qtlottie. We configure qtlottie as follows /target_qtbase/bin/qt-configure-module /qtlottie_src -- -DQT_ADDITIONAL_PACKAGES_PREFIX_PATH=/target_qtdeclarative We expect the target QtQuick package to be found, but it won't be. The reason is that QT_ADDITIONAL_PACKAGES_PREFIX_PATH is added to the PATHs option, but we don't adjust CMAKE_FIND_ROOT_PATH. Without adding the new paths in CMAKE_FIND_ROOT_PATH, CMake will re-root the passed PATHs under the existing CMAKE_FIND_ROOT_PATH, which is QT_TOOLCHAIN_RELOCATABLE_INSTALL_PREFIX, which evaluates to /target_qtbase. There is no QtQuick package there. To fix this, prepend the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH to CMAKE_FIND_ROOT_PATH. The location where we currently do CMAKE_FIND_ROOT_PATH manipulations is in the qt.toolchain.cmake file, so to be consistent, we prepend the new prefixes there as well. We need to adjust both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH, due the path re-rooting bug in CMake. See https://gitlab.kitware.com/cmake/cmake/-/issues/21937 as well as the existing comment in qt.toolchain.cmake marked with REROOT_PATH_ISSUE_MARKER. We also need to do a few more things to make the setup work Because Qt6Config uses NO_DEFAULT_PATH, the CMAKE_PREFIX_PATH adjustments we do in the toolchain file are not enough, so we still need to add the same prefixes to the Qt6Config find_package PATHS option. One would ask why do we need to adjust CMAKE_PREFIX_PATH at all then. It's for find_package(Qt6Foo) calls to work which don't go through the Qt6Config umbrella package. To make the CMake re-rooting behavior happy, we need to ensure the provided paths are absolute. So we iterate over the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH, to make them absolute. We do the same for the environment variable. We need to append lib/cmake to the prefixes which are added to CMAKE_PREFIX_PATH, otherwise the CMake re-rooting bug is hit. We need to specify the Qt6 package location (${_qt_cmake_dir}) to the PATHS option in the various Dependencies.cmake.in files, to ensure that dependency resolution can jump around between the Qt6 dir and the additional prefixes. Previously the dependency lookup code assumed that all dependencies would be within the same prefix. The same is needed for qt and qml plugin dependency lookup. Amends 7bb91398f25cb2016c0558fd397b376f413e3e96 Amends 60c87c68016c6f02b0eddd4002f75a49ab51d4a8 Amends 5bbd700124d13a292ff8bae6045316112500e230 Pick-to: 6.2 Fixes: QTBUG-95854 Change-Id: I35ae82330fec427d0d38fc9a0542ffafff52556a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 15:03:02 +00:00
endif()
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 <alexandru.croitor@qt.io>
2022-01-11 16:44:10 +00:00
foreach(additional_path IN LISTS additional_packages_prefixes)
file(TO_CMAKE_PATH "${additional_path}" additional_path)
CMake: Fix QT_ADDITIONAL_PACKAGES_PREFIX_PATH for cross-builds The QT_ADDITIONAL_PACKAGES_PREFIX_PATH variable was introduced to allow specifying extra locations to find Qt packages. The reason it was introduced instead of just using CMAKE_PREFIX_PATH is because the Qt6 component find_package call uses NO_DEFAULT_PATH which means CMAKE_PREFIX_PATH is ignored. We use NO_DEFAULT_PATH to ensure we don't accidentally pick up system / distro Qt packages. The paths from QT_ADDITIONAL_PACKAGES_PREFIX_PATH are added to the find_package PATHS option in the Qt6 package, each ModuleDependencies.cmake file and some other places. Unfortunately that's not enough to make it work for cross-builds. Imagine the following scenario. host qtbase, qtdeclarative installed in /host_qt target qtbase installed in /target_qtbase target qtdeclarative installed in /target_qtdeclarative We want to cross-build qtlottie. We configure qtlottie as follows /target_qtbase/bin/qt-configure-module /qtlottie_src -- -DQT_ADDITIONAL_PACKAGES_PREFIX_PATH=/target_qtdeclarative We expect the target QtQuick package to be found, but it won't be. The reason is that QT_ADDITIONAL_PACKAGES_PREFIX_PATH is added to the PATHs option, but we don't adjust CMAKE_FIND_ROOT_PATH. Without adding the new paths in CMAKE_FIND_ROOT_PATH, CMake will re-root the passed PATHs under the existing CMAKE_FIND_ROOT_PATH, which is QT_TOOLCHAIN_RELOCATABLE_INSTALL_PREFIX, which evaluates to /target_qtbase. There is no QtQuick package there. To fix this, prepend the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH to CMAKE_FIND_ROOT_PATH. The location where we currently do CMAKE_FIND_ROOT_PATH manipulations is in the qt.toolchain.cmake file, so to be consistent, we prepend the new prefixes there as well. We need to adjust both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH, due the path re-rooting bug in CMake. See https://gitlab.kitware.com/cmake/cmake/-/issues/21937 as well as the existing comment in qt.toolchain.cmake marked with REROOT_PATH_ISSUE_MARKER. We also need to do a few more things to make the setup work Because Qt6Config uses NO_DEFAULT_PATH, the CMAKE_PREFIX_PATH adjustments we do in the toolchain file are not enough, so we still need to add the same prefixes to the Qt6Config find_package PATHS option. One would ask why do we need to adjust CMAKE_PREFIX_PATH at all then. It's for find_package(Qt6Foo) calls to work which don't go through the Qt6Config umbrella package. To make the CMake re-rooting behavior happy, we need to ensure the provided paths are absolute. So we iterate over the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH, to make them absolute. We do the same for the environment variable. We need to append lib/cmake to the prefixes which are added to CMAKE_PREFIX_PATH, otherwise the CMake re-rooting bug is hit. We need to specify the Qt6 package location (${_qt_cmake_dir}) to the PATHS option in the various Dependencies.cmake.in files, to ensure that dependency resolution can jump around between the Qt6 dir and the additional prefixes. Previously the dependency lookup code assumed that all dependencies would be within the same prefix. The same is needed for qt and qml plugin dependency lookup. Amends 7bb91398f25cb2016c0558fd397b376f413e3e96 Amends 60c87c68016c6f02b0eddd4002f75a49ab51d4a8 Amends 5bbd700124d13a292ff8bae6045316112500e230 Pick-to: 6.2 Fixes: QTBUG-95854 Change-Id: I35ae82330fec427d0d38fc9a0542ffafff52556a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 15:03:02 +00:00
# The prefix paths need to end with lib/cmake to ensure the packages are found when
# cross compiling. Search for REROOT_PATH_ISSUE_MARKER in the qt.toolchain.cmake file for
# details.
# We must pass the values via the PATHS options because the main find_package call uses
# NO_DEFAULT_PATH, and thus CMAKE_PREFIX_PATH values are discarded.
# CMAKE_FIND_ROOT_PATH values are not discarded and togegher with the PATHS option, it
# ensures packages from additional prefixes are found.
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 <alexandru.croitor@qt.io>
2022-01-11 16:44:10 +00:00
if(NOT additional_path MATCHES "/lib/cmake$")
string(APPEND additional_path "/lib/cmake")
CMake: Fix QT_ADDITIONAL_PACKAGES_PREFIX_PATH for cross-builds The QT_ADDITIONAL_PACKAGES_PREFIX_PATH variable was introduced to allow specifying extra locations to find Qt packages. The reason it was introduced instead of just using CMAKE_PREFIX_PATH is because the Qt6 component find_package call uses NO_DEFAULT_PATH which means CMAKE_PREFIX_PATH is ignored. We use NO_DEFAULT_PATH to ensure we don't accidentally pick up system / distro Qt packages. The paths from QT_ADDITIONAL_PACKAGES_PREFIX_PATH are added to the find_package PATHS option in the Qt6 package, each ModuleDependencies.cmake file and some other places. Unfortunately that's not enough to make it work for cross-builds. Imagine the following scenario. host qtbase, qtdeclarative installed in /host_qt target qtbase installed in /target_qtbase target qtdeclarative installed in /target_qtdeclarative We want to cross-build qtlottie. We configure qtlottie as follows /target_qtbase/bin/qt-configure-module /qtlottie_src -- -DQT_ADDITIONAL_PACKAGES_PREFIX_PATH=/target_qtdeclarative We expect the target QtQuick package to be found, but it won't be. The reason is that QT_ADDITIONAL_PACKAGES_PREFIX_PATH is added to the PATHs option, but we don't adjust CMAKE_FIND_ROOT_PATH. Without adding the new paths in CMAKE_FIND_ROOT_PATH, CMake will re-root the passed PATHs under the existing CMAKE_FIND_ROOT_PATH, which is QT_TOOLCHAIN_RELOCATABLE_INSTALL_PREFIX, which evaluates to /target_qtbase. There is no QtQuick package there. To fix this, prepend the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH to CMAKE_FIND_ROOT_PATH. The location where we currently do CMAKE_FIND_ROOT_PATH manipulations is in the qt.toolchain.cmake file, so to be consistent, we prepend the new prefixes there as well. We need to adjust both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH, due the path re-rooting bug in CMake. See https://gitlab.kitware.com/cmake/cmake/-/issues/21937 as well as the existing comment in qt.toolchain.cmake marked with REROOT_PATH_ISSUE_MARKER. We also need to do a few more things to make the setup work Because Qt6Config uses NO_DEFAULT_PATH, the CMAKE_PREFIX_PATH adjustments we do in the toolchain file are not enough, so we still need to add the same prefixes to the Qt6Config find_package PATHS option. One would ask why do we need to adjust CMAKE_PREFIX_PATH at all then. It's for find_package(Qt6Foo) calls to work which don't go through the Qt6Config umbrella package. To make the CMake re-rooting behavior happy, we need to ensure the provided paths are absolute. So we iterate over the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH, to make them absolute. We do the same for the environment variable. We need to append lib/cmake to the prefixes which are added to CMAKE_PREFIX_PATH, otherwise the CMake re-rooting bug is hit. We need to specify the Qt6 package location (${_qt_cmake_dir}) to the PATHS option in the various Dependencies.cmake.in files, to ensure that dependency resolution can jump around between the Qt6 dir and the additional prefixes. Previously the dependency lookup code assumed that all dependencies would be within the same prefix. The same is needed for qt and qml plugin dependency lookup. Amends 7bb91398f25cb2016c0558fd397b376f413e3e96 Amends 60c87c68016c6f02b0eddd4002f75a49ab51d4a8 Amends 5bbd700124d13a292ff8bae6045316112500e230 Pick-to: 6.2 Fixes: QTBUG-95854 Change-Id: I35ae82330fec427d0d38fc9a0542ffafff52556a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 15:03:02 +00:00
endif()
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 <alexandru.croitor@qt.io>
2022-01-11 16:44:10 +00:00
list(APPEND additional_packages_prefix_paths "${additional_path}")
CMake: Fix QT_ADDITIONAL_PACKAGES_PREFIX_PATH for cross-builds The QT_ADDITIONAL_PACKAGES_PREFIX_PATH variable was introduced to allow specifying extra locations to find Qt packages. The reason it was introduced instead of just using CMAKE_PREFIX_PATH is because the Qt6 component find_package call uses NO_DEFAULT_PATH which means CMAKE_PREFIX_PATH is ignored. We use NO_DEFAULT_PATH to ensure we don't accidentally pick up system / distro Qt packages. The paths from QT_ADDITIONAL_PACKAGES_PREFIX_PATH are added to the find_package PATHS option in the Qt6 package, each ModuleDependencies.cmake file and some other places. Unfortunately that's not enough to make it work for cross-builds. Imagine the following scenario. host qtbase, qtdeclarative installed in /host_qt target qtbase installed in /target_qtbase target qtdeclarative installed in /target_qtdeclarative We want to cross-build qtlottie. We configure qtlottie as follows /target_qtbase/bin/qt-configure-module /qtlottie_src -- -DQT_ADDITIONAL_PACKAGES_PREFIX_PATH=/target_qtdeclarative We expect the target QtQuick package to be found, but it won't be. The reason is that QT_ADDITIONAL_PACKAGES_PREFIX_PATH is added to the PATHs option, but we don't adjust CMAKE_FIND_ROOT_PATH. Without adding the new paths in CMAKE_FIND_ROOT_PATH, CMake will re-root the passed PATHs under the existing CMAKE_FIND_ROOT_PATH, which is QT_TOOLCHAIN_RELOCATABLE_INSTALL_PREFIX, which evaluates to /target_qtbase. There is no QtQuick package there. To fix this, prepend the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH to CMAKE_FIND_ROOT_PATH. The location where we currently do CMAKE_FIND_ROOT_PATH manipulations is in the qt.toolchain.cmake file, so to be consistent, we prepend the new prefixes there as well. We need to adjust both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH, due the path re-rooting bug in CMake. See https://gitlab.kitware.com/cmake/cmake/-/issues/21937 as well as the existing comment in qt.toolchain.cmake marked with REROOT_PATH_ISSUE_MARKER. We also need to do a few more things to make the setup work Because Qt6Config uses NO_DEFAULT_PATH, the CMAKE_PREFIX_PATH adjustments we do in the toolchain file are not enough, so we still need to add the same prefixes to the Qt6Config find_package PATHS option. One would ask why do we need to adjust CMAKE_PREFIX_PATH at all then. It's for find_package(Qt6Foo) calls to work which don't go through the Qt6Config umbrella package. To make the CMake re-rooting behavior happy, we need to ensure the provided paths are absolute. So we iterate over the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH, to make them absolute. We do the same for the environment variable. We need to append lib/cmake to the prefixes which are added to CMAKE_PREFIX_PATH, otherwise the CMake re-rooting bug is hit. We need to specify the Qt6 package location (${_qt_cmake_dir}) to the PATHS option in the various Dependencies.cmake.in files, to ensure that dependency resolution can jump around between the Qt6 dir and the additional prefixes. Previously the dependency lookup code assumed that all dependencies would be within the same prefix. The same is needed for qt and qml plugin dependency lookup. Amends 7bb91398f25cb2016c0558fd397b376f413e3e96 Amends 60c87c68016c6f02b0eddd4002f75a49ab51d4a8 Amends 5bbd700124d13a292ff8bae6045316112500e230 Pick-to: 6.2 Fixes: QTBUG-95854 Change-Id: I35ae82330fec427d0d38fc9a0542ffafff52556a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 15:03:02 +00:00
endforeach()
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 <alexandru.croitor@qt.io>
2022-01-11 16:44:10 +00:00
set("${out_var}" "${additional_packages_prefix_paths}" PARENT_SCOPE)
endfunction()
__qt_internal_collect_additional_prefix_paths(_qt_additional_packages_prefix_paths
QT_ADDITIONAL_PACKAGES_PREFIX_PATH)
__qt_internal_collect_additional_prefix_paths(_qt_additional_host_packages_prefix_paths
QT_ADDITIONAL_HOST_PACKAGES_PREFIX_PATH)
# Take a list of prefix paths ending with "/lib/cmake", and return a list of absolute paths with
# "/lib/cmake" removed.
function(__qt_internal_prefix_paths_to_roots out_var prefix_paths)
set(result "")
foreach(path IN LISTS prefix_paths)
if(path MATCHES "/lib/cmake$")
string(APPEND path "/../..")
endif()
get_filename_component(path "${path}" ABSOLUTE)
list(APPEND result "${path}")
endforeach()
set("${out_var}" "${result}" PARENT_SCOPE)
endfunction()
__qt_internal_prefix_paths_to_roots(_qt_additional_host_packages_root_paths
"${_qt_additional_host_packages_prefix_paths}")
Improve support for QT_ADDITIONAL_PACKAGES_PREFIX_PATH Allow to set QT_ADDITIONAL_PACKAGES_PREFIX_PATH as both an env variable and CMake cache variable. Also normalize path and list separators, so that they can be used similar to CMAKE_PREFIX_PATH. The environment variable is intended to be set by the conan virtualenv generator, so that e.g. find_package(Qt6 COMPONENTS NetworkAuth REQUIRED) also works if NetworkAuth is not installed into the Qt prefix. Pick-to: 6.1 Fixes: QTBUG-91142 Change-Id: Ia9f9b9fa2b1b051d33073629139640d0f4c7a843 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io>
2021-02-24 15:07:37 +00:00
CMake: Refactor handling of static plugins Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 13:25:18 +00:00
# Public helpers available to all Qt packages.
include("${CMAKE_CURRENT_LIST_DIR}/QtFeature.cmake")
Implement propagation of object files to the end-point executable This proposal collects all the resource objects to the qt-specific property of the static libraries. This is done to avoid littering of other static libraries and put resource object files to the source part of the linker line when linking the end-point executable. The way we link object resource libraries is changed back to the target_link_libraries approach as we may omit using finalizers with linkers other than ld. Users may enforce finalizers by calling the qt6_enable_resource_objects_finalizer_mode function if need. Refactor tests related to the static resources. Amends ddaa7150d85624ab545ccfe098fe8b2d18241940 Task-number: QTBUG-93002 Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-19 17:46:24 +00:00
include("${CMAKE_CURRENT_LIST_DIR}/QtPublicFinalizerHelpers.cmake")
CMake: Refactor handling of static plugins Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 13:25:18 +00:00
include("${CMAKE_CURRENT_LIST_DIR}/QtPublicPluginHelpers.cmake")
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
include("${CMAKE_CURRENT_LIST_DIR}/QtPublicTargetHelpers.cmake")
include("${CMAKE_CURRENT_LIST_DIR}/QtPublicWalkLibsHelpers.cmake")
CMake: Add public FindPackageHelpers This makes qt_internal_disable_find_package_global_promotion available, which is needed when linking against QtMultimedia in a static build Pick-to: 6.2 Change-Id: I9b8f6d7b74a8693ac471f8a280e893f4da80a44b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-14 14:24:57 +00:00
include("${CMAKE_CURRENT_LIST_DIR}/QtPublicFindPackageHelpers.cmake")
Move dependency lookup functionality to the common macro Dependency lookup mechanism is the same for modules and plugins. It makes sense to wrap it using macro. Pick-to: 6.2 Change-Id: I73727743b0f5f40b2d94624f65ebfcf85e8dcc59 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-17 14:18:59 +00:00
include("${CMAKE_CURRENT_LIST_DIR}/QtPublicDependencyHelpers.cmake")
Use IMPORTED_LOCATION of rcc target Use IMPORTED_LOCATION of rcc target when generating Android deployment settings, instead of the hardcoded host path. Introduce a helper function to find the location of the imported tool target. Change-Id: Icfa51ee7a01b3f58fc4892da03055f9ed531cc0b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-01-27 15:28:47 +00:00
include("${CMAKE_CURRENT_LIST_DIR}/QtPublicToolHelpers.cmake")
Use 'copy' but not 'copy_if_different' on Windows platforms Use custom script to copy big Android artifacts on Windows platforms. The script uses 'copy' but not 'copy_if_different' when source file size is bigger than 2GB. 'cmake -E copy_if_different' only compares first 2GB of files because of cmake issue, so this step only workaround the problem. Pick-to: 6.2 6.3 Task-number: QTBUG-99491 Change-Id: Id076734700e334dfc3330da412462c2b53829b33 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-12-29 17:00:52 +00:00
include("${CMAKE_CURRENT_LIST_DIR}/QtPublicCMakeHelpers.cmake")
CMake: Refactor handling of static plugins Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 13:25:18 +00:00
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 17:01:35 +00:00
if(NOT DEFINED QT_CMAKE_EXPORT_NAMESPACE)
set(QT_CMAKE_EXPORT_NAMESPACE @QT_CMAKE_EXPORT_NAMESPACE@)
endif()
CMake: Propagate sanitizer flags to public projects Ensure that Qt user projects build with sanitizer flags if Qt was configured with any of the sanitizers enabled. To compile Qt with sanitizer support enable any of Qt sanitizer features. Passing -DECM_ENABLE_SANITIZERS=address to CMake is NOT supported anymore. When configuring Qt using CMake directly, pass -DFEATURE_sanitizer_address=ON -DFEATURE_sanitizer_undefined=ON instead of -DECM_ENABLE_SANITIZERS=address;undefined When configuring Qt with the configure script pass -sanitize address -sanitize undefined as usual. QtConfig.cmake now records the sanitizer options that should be enabled for all consuming projects based on the enabled Qt features. This applies to internal Qt builds as well as well as tests an examples. The recorded sanitizer options are assigned to the ECM_ENABLE_SANITIZERS variable in the directory scope where find_package(Qt6) is called. The ECMEnableSanitizers module is included to add the necessary flags to all targets in that directory scope or its children. This behavior can be opted out by setting the QT_NO_ADD_SANITIZER_OPTIONS variable in projects that use Qt and might be handling sanitizer options differently. Amends 7e03bc39b8bcdaa4e83e72ac99e117561c124951 Pick-to: 6.2 Fixes: QTBUG-87989 Task-number: QTBUG-92083 Change-Id: I2e3371147277bdf8f55a39abaa34478dea4853a6 Reviewed-by: Robert Löhning <robert.loehning@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-06-24 10:30:32 +00:00
# Propagate sanitizer flags to both internal Qt builds and user projects.
# Allow opt-out in case if downstream projects handle it in a different way.
set(QT_CONFIGURED_SANITIZER_OPTIONS "@ECM_ENABLE_SANITIZERS@")
if(QT_CONFIGURED_SANITIZER_OPTIONS
AND NOT __qt_sanitizer_options_set
AND NOT QT_NO_ADD_SANITIZER_OPTIONS)
set(ECM_ENABLE_SANITIZERS "${QT_CONFIGURED_SANITIZER_OPTIONS}")
include(
"${CMAKE_CURRENT_LIST_DIR}/3rdparty/extra-cmake-modules/modules/ECMEnableSanitizers.cmake")
endif()
# Mark that the current directory scope has its sanitizer flags set.
set(__qt_sanitizer_options_set TRUE)
CMake: Properly handle CONFIG += thread aka Threads::Threads mkspecs/features/qt.prf adds a dependency on the system threading library if the Qt Core thread feature is enabled. Because qt.prf is loaded by any public or internal Qt project, it's essentially a public dependency for any Qt consumer. To mimic that in CMake, we check if the thread feature is enabled, and and set the Threads::Threads library as a dependency of Qt6::Platform, which is a public target used by all Qt modules and plugins and Qt consumers. We also need to create a Qt6Dependencies.cmake file so we find_package(Threads) every time find_package(Qt6) is called. For the .prl files to be usable, we have to filter out some CMake implementation specific directory separator tokens 'CMAKE_DIRECTORY_ID_SEP' aka '::@', which are added because we call target_link_libraries() with a target created in a different scope (I think). As a result of this change, we shouldn't have to hardcode Threads::Threads in other projects, because it's now a global public dependency. Task-number: QTBUG-85801 Task-number: QTBUG-85877 Change-Id: Ib5d662c43b28e63f7da49d3bd77d0ad751220b31 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-03 14:28:16 +00:00
# Find required dependencies, if any.
include(CMakeFindDependencyMacro)
if(EXISTS "${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@Dependencies.cmake")
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@Dependencies.cmake")
CMake: Suggest hints on how to debug missing packages Depending on CMake version suggest usage of either --debug-find-pkg or CMAKE_FIND_DEBUG_MODE to help troubleshoot why dependent packages are not found. To achieve that, append the hint message to the _NOT_FOUND_MESSAGE. To ensure it works for qt dependencies, and not only tool and 3rd party dependencies, _qt_internal_find_qt_dependencies is modified to set variable names infixed by the target name, so the name is consistent with the other dependency lookup functions. The check and message are also added when a Qt6 component is not found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I4ef23d1c53ac8e04eb72c260d6860c1eeec8d7a3 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-14 13:28:12 +00:00
CMake: Introduce QT_DEBUG_FIND_PACKAGE for troubleshooting When a Qt component or dependency is not found, we will now show a message that the user can reconfigure the project with -DQT_DEBUG_FIND_PACKAGE=ON. If the option is enabled, various variables that find_package uses to find packages (like CMAKE_PREFIX_PATH, CMAKE_FIND_ROOT_PATH) will be recorded before each find_package / find_dependency call that is executed in any of the Qt package files. If any find_package call fails (a package has its _FOUND variable set to 0), the values of all those recorded variables will be shown. This is useful to troubleshoot issues, especially when cross-compiling, without having to manually modify the various Config files. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I3654960597911bd704fbe3c419bcae347ab739a9 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-14 15:00:56 +00:00
_qt_internal_suggest_dependency_debugging(@INSTALL_CMAKE_NAMESPACE@
CMake: Suggest hints on how to debug missing packages Depending on CMake version suggest usage of either --debug-find-pkg or CMAKE_FIND_DEBUG_MODE to help troubleshoot why dependent packages are not found. To achieve that, append the hint message to the _NOT_FOUND_MESSAGE. To ensure it works for qt dependencies, and not only tool and 3rd party dependencies, _qt_internal_find_qt_dependencies is modified to set variable names infixed by the target name, so the name is consistent with the other dependency lookup functions. The check and message are also added when a Qt6 component is not found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I4ef23d1c53ac8e04eb72c260d6860c1eeec8d7a3 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-14 13:28:12 +00:00
__qt_@INSTALL_CMAKE_NAMESPACE@_pkg ${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE)
CMake: Remove custom Qt6 3rd party dependency implementation Use _qt_internal_find_third_party_dependencies instead. We rely on the inner find_dependency call to set the Qt6_NOT_FOUND_MESSAGE message when a dependency is not found. This implies removing the custom FATAL_ERROR handling and relying on the parent find_package to display the Qt6_NOT_FOUND_MESSAGE message. We also clear Qt6_FIND_COMPONENTS if a dependency is not found. No need to look for Qt packages if the Qt6 dependency was not met. This reduces the amount of recursive error messages. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I5c611aaededfa63eb507ec5385b37a2fb6fcc698 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-13 15:44:55 +00:00
if(NOT @INSTALL_CMAKE_NAMESPACE@_FOUND)
# Clear the components, no need to look for them if dependencies were not found, otherwise
# you get a wall of recursive error messages.
set(@INSTALL_CMAKE_NAMESPACE@_FIND_COMPONENTS "")
Revert "Revert "CMake: Fix usage of find_dependency()"" ...and fix the build errors the original change caused. This reverts commit 127fb8bb5587db52216d0ac934f3111170a7cbe3. Change-Id: I4006b32734a51c5d101dd73c957f81d2a0f84ba1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-14 07:06:58 +00:00
endif()
CMake: Properly handle CONFIG += thread aka Threads::Threads mkspecs/features/qt.prf adds a dependency on the system threading library if the Qt Core thread feature is enabled. Because qt.prf is loaded by any public or internal Qt project, it's essentially a public dependency for any Qt consumer. To mimic that in CMake, we check if the thread feature is enabled, and and set the Threads::Threads library as a dependency of Qt6::Platform, which is a public target used by all Qt modules and plugins and Qt consumers. We also need to create a Qt6Dependencies.cmake file so we find_package(Threads) every time find_package(Qt6) is called. For the .prl files to be usable, we have to filter out some CMake implementation specific directory separator tokens 'CMAKE_DIRECTORY_ID_SEP' aka '::@', which are added because we call target_link_libraries() with a target created in a different scope (I think). As a result of this change, we shouldn't have to hardcode Threads::Threads in other projects, because it's now a global public dependency. Task-number: QTBUG-85801 Task-number: QTBUG-85877 Change-Id: Ib5d662c43b28e63f7da49d3bd77d0ad751220b31 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-03 14:28:16 +00:00
endif()
CMake: Partially fix QUIETness of find_package(Qt6 COMPONENTS Foo) When Qt5Config.cmake was ported to Qt6, the assignment of _Qt6_FIND_PARTS_QUIET was accidentally left out. Make sure that when find_package(Qt6 QUIET COMPONENTS Foo) is called, the underlying component find_package(Qt6Foo) call gets a QUIET option as well. This will silence short-form warnings like -- Could NOT find Qt6Foo (missing: Qt6Foo_DIR) It currently won't silence any warnings produced by the transitive find_package calls in QtModuleDependencies.cmake. That will require a separate change. Remove usage of _Qt6_FIND_PARTS_REQUIRED which was always empty. See details of QTBUG-95573 why it's currently not used. Pick-to: 6.2 Task-number: QTBUG-95573 Change-Id: I3822c068eecbe84c306a1b04f4187278d35ec3d5 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-04 10:23:14 +00:00
set(_@INSTALL_CMAKE_NAMESPACE@_FIND_PARTS_QUIET)
if(@INSTALL_CMAKE_NAMESPACE@_FIND_QUIETLY)
set(_@INSTALL_CMAKE_NAMESPACE@_FIND_PARTS_QUIET QUIET)
endif()
CMake: Allow finding Qt CMake packages in additional locations By default, when using the Qt6 CMake package to look for components, the find_package() calls for the components use NO_DEFAULT_PATH to ensure that CMake doesn't accidentally find system (distro) packages. Instead we limit the paths to one level up from where the Qt6 package is. Unfortunately that doesn't quite work for finding Qt packages that might have been installed into a different prefix than where the main Qt prefix is. This happens when Qt addons are built by Conan, and installed into a separate prefix. To allow calls like find_package(Qt6 COMPONENTS ConanAddon) to work in a scenario as described above, introduce a new variable called QT_ADDITIONAL_PACKAGES_PREFIX_PATH which can be used to specify additional paths where Qt CMake packages should be found. This is similar to previously introduced QT_EXAMPLES_CMAKE_PREFIX_PATH variable which was meant for a similar case, but only for examples. Additionally, allow disabling the NO_DEFAULT_PATH option by setting the QT_DISABLE_NO_DEFAULT_PATH_IN_QT_PACKAGES cache variable to TRUE. This would allow regular usage of CMAKE_PREFIX_PATH to work, at the risk that system Qt CMake packages might be found. Augments 5cd4001bf2a7f0894c6ac269860e833b02df6cde and ffe088941378e32ea30c142cca7e63c537a41ff1. Fixes: QTBUG-86882 Change-Id: Ia8e060cbba6d2a10c3d63d81892f2c71e4236a9a Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-09-25 18:02:56 +00:00
set(__qt_use_no_default_path_for_qt_packages "NO_DEFAULT_PATH")
if(QT_DISABLE_NO_DEFAULT_PATH_IN_QT_PACKAGES)
set(__qt_use_no_default_path_for_qt_packages "")
endif()
cmake: Make find_package(Qt5 ...) work properly Introduce a new cached variable INSTALL_CMAKE_NAMESPACE for defining the prefix used for CMake config files (c.f. "${PREFIX}Core/${PREFIX}CoreConfig.cmake") Also make sure to `find_dependency(...)` the required packages inside the individual CMake config files. I.e. in Qt5WidgetsConfig.cmake, search for Qt5Core, etc. pp.. Change-Id: Idc027925fe9d5323091c4853803ad5ce44b1afc6 Reviewed-by: Jean-Michaël Celerier <jean-michael.celerier@kdab.com> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-02-11 10:34:35 +00:00
foreach(module ${@INSTALL_CMAKE_NAMESPACE@_FIND_COMPONENTS})
Pick up *Tools components also from host Qt Let find_package(Qt6 COMPONENTS LinguistTools) for a cross-compiled Qt fall back to search LinguistTools in the host Qt. Use the same trick as in QtModuleDependencies.cmake: Prepend both CMAKE_PREFIX_PATH and CMAKE_FIND_ROOT_PATH with the QT_HOST_PATH (respective ${QT_HOST_PATH}/lib/cmake). Furthermore adding ${QT_HOST_PATH}/lib/cmake to PATHS argument makes sure that find_package will work even with NO_DEFAULT_PATH. Make sure not to match ShaderTools and Tools packages. ShaderTools is the cross-compiled package, the host package name is ShaderToolsTools. Tools is the cross-compiled module from qttools. Allow an opt out via a QT_NO_FIND_HOST_TOOLS_PATH_MANIPULATION variable in case that we accidentally match more packages ending in Tools that are actually cross-compiled packages. Pick-to: 6.1 6.2 Fixes: QTBUG-95602 Change-Id: Ib0a787716fa529e36f22356da069e705d9eed5fa Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-04 15:36:22 +00:00
if(NOT "${QT_HOST_PATH}" STREQUAL ""
AND "${module}" MATCHES "Tools$"
CMake: Fix host UiTools being picked up instead of target one Pick-to: 6.2 6.3 Fixes: QTBUG-100233 Change-Id: Id4b30841ba9e499f462325f882218edf407e0a00 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-01-26 13:33:31 +00:00
AND NOT "${module}" MATCHES "UiTools$"
Pick up *Tools components also from host Qt Let find_package(Qt6 COMPONENTS LinguistTools) for a cross-compiled Qt fall back to search LinguistTools in the host Qt. Use the same trick as in QtModuleDependencies.cmake: Prepend both CMAKE_PREFIX_PATH and CMAKE_FIND_ROOT_PATH with the QT_HOST_PATH (respective ${QT_HOST_PATH}/lib/cmake). Furthermore adding ${QT_HOST_PATH}/lib/cmake to PATHS argument makes sure that find_package will work even with NO_DEFAULT_PATH. Make sure not to match ShaderTools and Tools packages. ShaderTools is the cross-compiled package, the host package name is ShaderToolsTools. Tools is the cross-compiled module from qttools. Allow an opt out via a QT_NO_FIND_HOST_TOOLS_PATH_MANIPULATION variable in case that we accidentally match more packages ending in Tools that are actually cross-compiled packages. Pick-to: 6.1 6.2 Fixes: QTBUG-95602 Change-Id: Ib0a787716fa529e36f22356da069e705d9eed5fa Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-04 15:36:22 +00:00
AND NOT "${module}" MATCHES "ShaderTools$"
AND NOT "${module}" MATCHES "^Tools$"
AND NOT QT_NO_FIND_HOST_TOOLS_PATH_MANIPULATION)
# Make sure that a Qt*Tools package is also looked up in QT_HOST_PATH.
# But don't match QtShaderTools and QtTools which are cross-compiled target package names.
# Allow opt out just in case.
CMake: Use Qt6HostInfo dir for Tools CMAKE_PREFIX_PATH assignment Instead of hard-coding a lib/cmake suffix to CMAKE_PREFIX_PATH use the parent directory of the Qt6HostInfo package which is always searched for when QT_HOST_PATH is set. Amends d2359b2d4e5db6c42158d536d6e2a2af5ea1e59c Pick-to: 6.2 Change-Id: I7f3c8fe17bc82f733580d68d928146434a57d849 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-10-20 15:52:00 +00:00
get_filename_component(__qt_find_package_host_qt_path
"${Qt@PROJECT_VERSION_MAJOR@HostInfo_DIR}/.." ABSOLUTE)
Pick up *Tools components also from host Qt Let find_package(Qt6 COMPONENTS LinguistTools) for a cross-compiled Qt fall back to search LinguistTools in the host Qt. Use the same trick as in QtModuleDependencies.cmake: Prepend both CMAKE_PREFIX_PATH and CMAKE_FIND_ROOT_PATH with the QT_HOST_PATH (respective ${QT_HOST_PATH}/lib/cmake). Furthermore adding ${QT_HOST_PATH}/lib/cmake to PATHS argument makes sure that find_package will work even with NO_DEFAULT_PATH. Make sure not to match ShaderTools and Tools packages. ShaderTools is the cross-compiled package, the host package name is ShaderToolsTools. Tools is the cross-compiled module from qttools. Allow an opt out via a QT_NO_FIND_HOST_TOOLS_PATH_MANIPULATION variable in case that we accidentally match more packages ending in Tools that are actually cross-compiled packages. Pick-to: 6.1 6.2 Fixes: QTBUG-95602 Change-Id: Ib0a787716fa529e36f22356da069e705d9eed5fa Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-04 15:36:22 +00:00
set(__qt_backup_cmake_prefix_path "${CMAKE_PREFIX_PATH}")
set(__qt_backup_cmake_find_root_path "${CMAKE_FIND_ROOT_PATH}")
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 <alexandru.croitor@qt.io>
2022-01-11 16:44:10 +00:00
list(PREPEND CMAKE_PREFIX_PATH "${__qt_find_package_host_qt_path}"
${_qt_additional_host_packages_prefix_paths})
list(PREPEND CMAKE_FIND_ROOT_PATH "${QT_HOST_PATH}"
${_qt_additional_host_packages_root_paths})
Pick up *Tools components also from host Qt Let find_package(Qt6 COMPONENTS LinguistTools) for a cross-compiled Qt fall back to search LinguistTools in the host Qt. Use the same trick as in QtModuleDependencies.cmake: Prepend both CMAKE_PREFIX_PATH and CMAKE_FIND_ROOT_PATH with the QT_HOST_PATH (respective ${QT_HOST_PATH}/lib/cmake). Furthermore adding ${QT_HOST_PATH}/lib/cmake to PATHS argument makes sure that find_package will work even with NO_DEFAULT_PATH. Make sure not to match ShaderTools and Tools packages. ShaderTools is the cross-compiled package, the host package name is ShaderToolsTools. Tools is the cross-compiled module from qttools. Allow an opt out via a QT_NO_FIND_HOST_TOOLS_PATH_MANIPULATION variable in case that we accidentally match more packages ending in Tools that are actually cross-compiled packages. Pick-to: 6.1 6.2 Fixes: QTBUG-95602 Change-Id: Ib0a787716fa529e36f22356da069e705d9eed5fa Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-04 15:36:22 +00:00
endif()
CMake: Introduce QT_DEBUG_FIND_PACKAGE for troubleshooting When a Qt component or dependency is not found, we will now show a message that the user can reconfigure the project with -DQT_DEBUG_FIND_PACKAGE=ON. If the option is enabled, various variables that find_package uses to find packages (like CMAKE_PREFIX_PATH, CMAKE_FIND_ROOT_PATH) will be recorded before each find_package / find_dependency call that is executed in any of the Qt package files. If any find_package call fails (a package has its _FOUND variable set to 0), the values of all those recorded variables will be shown. This is useful to troubleshoot issues, especially when cross-compiling, without having to manually modify the various Config files. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I3654960597911bd704fbe3c419bcae347ab739a9 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-14 15:00:56 +00:00
_qt_internal_save_find_package_context_for_debugging(@INSTALL_CMAKE_NAMESPACE@${module})
cmake: Make find_package(Qt5 ...) work properly Introduce a new cached variable INSTALL_CMAKE_NAMESPACE for defining the prefix used for CMake config files (c.f. "${PREFIX}Core/${PREFIX}CoreConfig.cmake") Also make sure to `find_dependency(...)` the required packages inside the individual CMake config files. I.e. in Qt5WidgetsConfig.cmake, search for Qt5Core, etc. pp.. Change-Id: Idc027925fe9d5323091c4853803ad5ce44b1afc6 Reviewed-by: Jean-Michaël Celerier <jean-michael.celerier@kdab.com> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-02-11 10:34:35 +00:00
find_package(@INSTALL_CMAKE_NAMESPACE@${module}
CMake: Pass Qt6_FIND_VERSION in Qt6Config when looking for components Pass Qt6_FIND_VERSION to components when the find_package(Qt6 ${ver} COMPONENTS Foo) signature is used. Create a ConfigVersion file for BuildInternals, so that BuildInternals passes the version check. Fix qt_configure_file to look in the _qt_6_config_cmake_dir folder for the template file rather than Qt6_DIR, because Qt6_DIR might be accidentally unset after a failed find_package(Qt6) call and the error is not helpful then. We already pass versions everywhere else when looking for dependencies, like in ModuleDependencies.cmake.in, PluginDependencies.cmake.in, ModuleToolsDependencies.cmake.in. Pick-to: 6.2 Fixes: QTBUG-91737 Change-Id: Ief1da0c6f239c935385e7ce662951e85ccfdf130 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-18 16:41:18 +00:00
${@INSTALL_CMAKE_NAMESPACE@_FIND_VERSION}
cmake: Make find_package(Qt5 ...) work properly Introduce a new cached variable INSTALL_CMAKE_NAMESPACE for defining the prefix used for CMake config files (c.f. "${PREFIX}Core/${PREFIX}CoreConfig.cmake") Also make sure to `find_dependency(...)` the required packages inside the individual CMake config files. I.e. in Qt5WidgetsConfig.cmake, search for Qt5Core, etc. pp.. Change-Id: Idc027925fe9d5323091c4853803ad5ce44b1afc6 Reviewed-by: Jean-Michaël Celerier <jean-michael.celerier@kdab.com> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-02-11 10:34:35 +00:00
${_@INSTALL_CMAKE_NAMESPACE@_FIND_PARTS_QUIET}
CMake: Allow finding Qt CMake packages in additional locations By default, when using the Qt6 CMake package to look for components, the find_package() calls for the components use NO_DEFAULT_PATH to ensure that CMake doesn't accidentally find system (distro) packages. Instead we limit the paths to one level up from where the Qt6 package is. Unfortunately that doesn't quite work for finding Qt packages that might have been installed into a different prefix than where the main Qt prefix is. This happens when Qt addons are built by Conan, and installed into a separate prefix. To allow calls like find_package(Qt6 COMPONENTS ConanAddon) to work in a scenario as described above, introduce a new variable called QT_ADDITIONAL_PACKAGES_PREFIX_PATH which can be used to specify additional paths where Qt CMake packages should be found. This is similar to previously introduced QT_EXAMPLES_CMAKE_PREFIX_PATH variable which was meant for a similar case, but only for examples. Additionally, allow disabling the NO_DEFAULT_PATH option by setting the QT_DISABLE_NO_DEFAULT_PATH_IN_QT_PACKAGES cache variable to TRUE. This would allow regular usage of CMAKE_PREFIX_PATH to work, at the risk that system Qt CMake packages might be found. Augments 5cd4001bf2a7f0894c6ac269860e833b02df6cde and ffe088941378e32ea30c142cca7e63c537a41ff1. Fixes: QTBUG-86882 Change-Id: Ia8e060cbba6d2a10c3d63d81892f2c71e4236a9a Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-09-25 18:02:56 +00:00
PATHS
${_qt_cmake_dir}
CMake: Fix QT_ADDITIONAL_PACKAGES_PREFIX_PATH for cross-builds The QT_ADDITIONAL_PACKAGES_PREFIX_PATH variable was introduced to allow specifying extra locations to find Qt packages. The reason it was introduced instead of just using CMAKE_PREFIX_PATH is because the Qt6 component find_package call uses NO_DEFAULT_PATH which means CMAKE_PREFIX_PATH is ignored. We use NO_DEFAULT_PATH to ensure we don't accidentally pick up system / distro Qt packages. The paths from QT_ADDITIONAL_PACKAGES_PREFIX_PATH are added to the find_package PATHS option in the Qt6 package, each ModuleDependencies.cmake file and some other places. Unfortunately that's not enough to make it work for cross-builds. Imagine the following scenario. host qtbase, qtdeclarative installed in /host_qt target qtbase installed in /target_qtbase target qtdeclarative installed in /target_qtdeclarative We want to cross-build qtlottie. We configure qtlottie as follows /target_qtbase/bin/qt-configure-module /qtlottie_src -- -DQT_ADDITIONAL_PACKAGES_PREFIX_PATH=/target_qtdeclarative We expect the target QtQuick package to be found, but it won't be. The reason is that QT_ADDITIONAL_PACKAGES_PREFIX_PATH is added to the PATHs option, but we don't adjust CMAKE_FIND_ROOT_PATH. Without adding the new paths in CMAKE_FIND_ROOT_PATH, CMake will re-root the passed PATHs under the existing CMAKE_FIND_ROOT_PATH, which is QT_TOOLCHAIN_RELOCATABLE_INSTALL_PREFIX, which evaluates to /target_qtbase. There is no QtQuick package there. To fix this, prepend the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH to CMAKE_FIND_ROOT_PATH. The location where we currently do CMAKE_FIND_ROOT_PATH manipulations is in the qt.toolchain.cmake file, so to be consistent, we prepend the new prefixes there as well. We need to adjust both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH, due the path re-rooting bug in CMake. See https://gitlab.kitware.com/cmake/cmake/-/issues/21937 as well as the existing comment in qt.toolchain.cmake marked with REROOT_PATH_ISSUE_MARKER. We also need to do a few more things to make the setup work Because Qt6Config uses NO_DEFAULT_PATH, the CMAKE_PREFIX_PATH adjustments we do in the toolchain file are not enough, so we still need to add the same prefixes to the Qt6Config find_package PATHS option. One would ask why do we need to adjust CMAKE_PREFIX_PATH at all then. It's for find_package(Qt6Foo) calls to work which don't go through the Qt6Config umbrella package. To make the CMake re-rooting behavior happy, we need to ensure the provided paths are absolute. So we iterate over the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH, to make them absolute. We do the same for the environment variable. We need to append lib/cmake to the prefixes which are added to CMAKE_PREFIX_PATH, otherwise the CMake re-rooting bug is hit. We need to specify the Qt6 package location (${_qt_cmake_dir}) to the PATHS option in the various Dependencies.cmake.in files, to ensure that dependency resolution can jump around between the Qt6 dir and the additional prefixes. Previously the dependency lookup code assumed that all dependencies would be within the same prefix. The same is needed for qt and qml plugin dependency lookup. Amends 7bb91398f25cb2016c0558fd397b376f413e3e96 Amends 60c87c68016c6f02b0eddd4002f75a49ab51d4a8 Amends 5bbd700124d13a292ff8bae6045316112500e230 Pick-to: 6.2 Fixes: QTBUG-95854 Change-Id: I35ae82330fec427d0d38fc9a0542ffafff52556a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 15:03:02 +00:00
${_qt_additional_packages_prefix_paths}
CMake: Allow finding Qt CMake packages in additional locations By default, when using the Qt6 CMake package to look for components, the find_package() calls for the components use NO_DEFAULT_PATH to ensure that CMake doesn't accidentally find system (distro) packages. Instead we limit the paths to one level up from where the Qt6 package is. Unfortunately that doesn't quite work for finding Qt packages that might have been installed into a different prefix than where the main Qt prefix is. This happens when Qt addons are built by Conan, and installed into a separate prefix. To allow calls like find_package(Qt6 COMPONENTS ConanAddon) to work in a scenario as described above, introduce a new variable called QT_ADDITIONAL_PACKAGES_PREFIX_PATH which can be used to specify additional paths where Qt CMake packages should be found. This is similar to previously introduced QT_EXAMPLES_CMAKE_PREFIX_PATH variable which was meant for a similar case, but only for examples. Additionally, allow disabling the NO_DEFAULT_PATH option by setting the QT_DISABLE_NO_DEFAULT_PATH_IN_QT_PACKAGES cache variable to TRUE. This would allow regular usage of CMAKE_PREFIX_PATH to work, at the risk that system Qt CMake packages might be found. Augments 5cd4001bf2a7f0894c6ac269860e833b02df6cde and ffe088941378e32ea30c142cca7e63c537a41ff1. Fixes: QTBUG-86882 Change-Id: Ia8e060cbba6d2a10c3d63d81892f2c71e4236a9a Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-09-25 18:02:56 +00:00
${QT_EXAMPLES_CMAKE_PREFIX_PATH}
Pick up *Tools components also from host Qt Let find_package(Qt6 COMPONENTS LinguistTools) for a cross-compiled Qt fall back to search LinguistTools in the host Qt. Use the same trick as in QtModuleDependencies.cmake: Prepend both CMAKE_PREFIX_PATH and CMAKE_FIND_ROOT_PATH with the QT_HOST_PATH (respective ${QT_HOST_PATH}/lib/cmake). Furthermore adding ${QT_HOST_PATH}/lib/cmake to PATHS argument makes sure that find_package will work even with NO_DEFAULT_PATH. Make sure not to match ShaderTools and Tools packages. ShaderTools is the cross-compiled package, the host package name is ShaderToolsTools. Tools is the cross-compiled module from qttools. Allow an opt out via a QT_NO_FIND_HOST_TOOLS_PATH_MANIPULATION variable in case that we accidentally match more packages ending in Tools that are actually cross-compiled packages. Pick-to: 6.1 6.2 Fixes: QTBUG-95602 Change-Id: Ib0a787716fa529e36f22356da069e705d9eed5fa Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-04 15:36:22 +00:00
${__qt_find_package_host_qt_path}
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 <alexandru.croitor@qt.io>
2022-01-11 16:44:10 +00:00
${_qt_additional_host_packages_prefix_paths}
CMake: Allow finding Qt CMake packages in additional locations By default, when using the Qt6 CMake package to look for components, the find_package() calls for the components use NO_DEFAULT_PATH to ensure that CMake doesn't accidentally find system (distro) packages. Instead we limit the paths to one level up from where the Qt6 package is. Unfortunately that doesn't quite work for finding Qt packages that might have been installed into a different prefix than where the main Qt prefix is. This happens when Qt addons are built by Conan, and installed into a separate prefix. To allow calls like find_package(Qt6 COMPONENTS ConanAddon) to work in a scenario as described above, introduce a new variable called QT_ADDITIONAL_PACKAGES_PREFIX_PATH which can be used to specify additional paths where Qt CMake packages should be found. This is similar to previously introduced QT_EXAMPLES_CMAKE_PREFIX_PATH variable which was meant for a similar case, but only for examples. Additionally, allow disabling the NO_DEFAULT_PATH option by setting the QT_DISABLE_NO_DEFAULT_PATH_IN_QT_PACKAGES cache variable to TRUE. This would allow regular usage of CMAKE_PREFIX_PATH to work, at the risk that system Qt CMake packages might be found. Augments 5cd4001bf2a7f0894c6ac269860e833b02df6cde and ffe088941378e32ea30c142cca7e63c537a41ff1. Fixes: QTBUG-86882 Change-Id: Ia8e060cbba6d2a10c3d63d81892f2c71e4236a9a Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-09-25 18:02:56 +00:00
${__qt_use_no_default_path_for_qt_packages}
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
)
Pick up *Tools components also from host Qt Let find_package(Qt6 COMPONENTS LinguistTools) for a cross-compiled Qt fall back to search LinguistTools in the host Qt. Use the same trick as in QtModuleDependencies.cmake: Prepend both CMAKE_PREFIX_PATH and CMAKE_FIND_ROOT_PATH with the QT_HOST_PATH (respective ${QT_HOST_PATH}/lib/cmake). Furthermore adding ${QT_HOST_PATH}/lib/cmake to PATHS argument makes sure that find_package will work even with NO_DEFAULT_PATH. Make sure not to match ShaderTools and Tools packages. ShaderTools is the cross-compiled package, the host package name is ShaderToolsTools. Tools is the cross-compiled module from qttools. Allow an opt out via a QT_NO_FIND_HOST_TOOLS_PATH_MANIPULATION variable in case that we accidentally match more packages ending in Tools that are actually cross-compiled packages. Pick-to: 6.1 6.2 Fixes: QTBUG-95602 Change-Id: Ib0a787716fa529e36f22356da069e705d9eed5fa Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-04 15:36:22 +00:00
if(NOT "${__qt_find_package_host_qt_path}" STREQUAL "")
set(CMAKE_PREFIX_PATH "${__qt_backup_cmake_prefix_path}")
set(CMAKE_FIND_ROOT_PATH "${__qt_backup_cmake_find_root_path}")
unset(__qt_backup_cmake_prefix_path)
unset(__qt_backup_cmake_find_root_path)
unset(__qt_find_package_host_qt_path)
endif()
cmake: Make find_package(Qt5 ...) work properly Introduce a new cached variable INSTALL_CMAKE_NAMESPACE for defining the prefix used for CMake config files (c.f. "${PREFIX}Core/${PREFIX}CoreConfig.cmake") Also make sure to `find_dependency(...)` the required packages inside the individual CMake config files. I.e. in Qt5WidgetsConfig.cmake, search for Qt5Core, etc. pp.. Change-Id: Idc027925fe9d5323091c4853803ad5ce44b1afc6 Reviewed-by: Jean-Michaël Celerier <jean-michael.celerier@kdab.com> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-02-11 10:34:35 +00:00
if (NOT @INSTALL_CMAKE_NAMESPACE@${module}_FOUND)
CMake: Improve component / package not found error messages Provide better error messages when a Qt package / component is not found. Mention the location of the expected Config file on the file system, whether it exists Also mention the location of the Config file that was specified by the user when configuring the project or which CMake computed and stored in QtModule_DIR cache var. Mention that a package is not found in case if the main target exposed by that package is not found. If the target is not found, mention that it might be due to QT_NO_CREATE_TARGETS being set to TRUE (when it is set to true). If it is set to true, the assumption is that the target must have been defined by something else before the find_package call (either an earlier find_package call without QT_NO_CREATE_TARGETS set to TRUE or maybe it's the use case of Qt being built together with its examples or it's a super build). Unset _Qt_NOTFOUND_MESSAGE to ensure that the Qt6 not found error message is not spilled into any subsequent find_package(Qt6) calls, causing a cascade of unwarranted warnings / errors. Make sure to unset it only if components were specified, so the message is not shown or unset in any of the recursive find_package(Qt6) calls which is a dependency for regular Qt module packages. This works fine, because find_package(Qt6) calls with components are only done in project code and not done by the transitive dependency code (which looks for Qt6Foo packages directly). Remove some dead code. Pick-to: 6.2 Task-number: QTBUG-95532 Change-Id: Ie93d18e25e33aa0fe9e9da9a60e3d3e4cd6adb58 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-02 14:02:04 +00:00
set(_qt_expected_component_config_path
"${_qt_cmake_dir}/@INSTALL_CMAKE_NAMESPACE@${module}/@INSTALL_CMAKE_NAMESPACE@${module}Config.cmake")
get_filename_component(
_qt_expected_component_dir_path "${_qt_expected_component_config_path}" DIRECTORY)
set(_qt_component_not_found_msg
"\nExpected Config file at \"${_qt_expected_component_config_path}\"")
if(EXISTS "${_qt_expected_component_config_path}")
string(APPEND _qt_component_not_found_msg " exists \n")
else()
string(APPEND _qt_component_not_found_msg " does NOT exist\n")
endif()
set(_qt_candidate_component_dir_path "${@INSTALL_CMAKE_NAMESPACE@${module}_DIR}")
if(_qt_candidate_component_dir_path AND
NOT _qt_expected_component_dir_path STREQUAL _qt_candidate_component_dir_path)
string(APPEND _qt_component_not_found_msg
"\n@INSTALL_CMAKE_NAMESPACE@${module}_DIR was computed by CMake or specified on the "
"command line by the user: \"${_qt_candidate_component_dir_path}\" "
"\nThe expected and computed paths are different, which might be the reason for "
"the package not to be found.")
endif()
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
CMake: Improve component / package not found error messages Provide better error messages when a Qt package / component is not found. Mention the location of the expected Config file on the file system, whether it exists Also mention the location of the Config file that was specified by the user when configuring the project or which CMake computed and stored in QtModule_DIR cache var. Mention that a package is not found in case if the main target exposed by that package is not found. If the target is not found, mention that it might be due to QT_NO_CREATE_TARGETS being set to TRUE (when it is set to true). If it is set to true, the assumption is that the target must have been defined by something else before the find_package call (either an earlier find_package call without QT_NO_CREATE_TARGETS set to TRUE or maybe it's the use case of Qt being built together with its examples or it's a super build). Unset _Qt_NOTFOUND_MESSAGE to ensure that the Qt6 not found error message is not spilled into any subsequent find_package(Qt6) calls, causing a cascade of unwarranted warnings / errors. Make sure to unset it only if components were specified, so the message is not shown or unset in any of the recursive find_package(Qt6) calls which is a dependency for regular Qt module packages. This works fine, because find_package(Qt6) calls with components are only done in project code and not done by the transitive dependency code (which looks for Qt6Foo packages directly). Remove some dead code. Pick-to: 6.2 Task-number: QTBUG-95532 Change-Id: Ie93d18e25e33aa0fe9e9da9a60e3d3e4cd6adb58 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-02 14:02:04 +00:00
if(@INSTALL_CMAKE_NAMESPACE@_FIND_REQUIRED_${module})
CMake: Suggest hints on how to debug missing packages Depending on CMake version suggest usage of either --debug-find-pkg or CMAKE_FIND_DEBUG_MODE to help troubleshoot why dependent packages are not found. To achieve that, append the hint message to the _NOT_FOUND_MESSAGE. To ensure it works for qt dependencies, and not only tool and 3rd party dependencies, _qt_internal_find_qt_dependencies is modified to set variable names infixed by the target name, so the name is consistent with the other dependency lookup functions. The check and message are also added when a Qt6 component is not found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I4ef23d1c53ac8e04eb72c260d6860c1eeec8d7a3 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-14 13:28:12 +00:00
set(@INSTALL_CMAKE_NAMESPACE@_FOUND False)
CMake: Improve component / package not found error messages Provide better error messages when a Qt package / component is not found. Mention the location of the expected Config file on the file system, whether it exists Also mention the location of the Config file that was specified by the user when configuring the project or which CMake computed and stored in QtModule_DIR cache var. Mention that a package is not found in case if the main target exposed by that package is not found. If the target is not found, mention that it might be due to QT_NO_CREATE_TARGETS being set to TRUE (when it is set to true). If it is set to true, the assumption is that the target must have been defined by something else before the find_package call (either an earlier find_package call without QT_NO_CREATE_TARGETS set to TRUE or maybe it's the use case of Qt being built together with its examples or it's a super build). Unset _Qt_NOTFOUND_MESSAGE to ensure that the Qt6 not found error message is not spilled into any subsequent find_package(Qt6) calls, causing a cascade of unwarranted warnings / errors. Make sure to unset it only if components were specified, so the message is not shown or unset in any of the recursive find_package(Qt6) calls which is a dependency for regular Qt module packages. This works fine, because find_package(Qt6) calls with components are only done in project code and not done by the transitive dependency code (which looks for Qt6Foo packages directly). Remove some dead code. Pick-to: 6.2 Task-number: QTBUG-95532 Change-Id: Ie93d18e25e33aa0fe9e9da9a60e3d3e4cd6adb58 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-02 14:02:04 +00:00
set(_Qt_NOTFOUND_MESSAGE
CMake: Clarify if an optional or required Qt component is not found Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: Id35f128404eb49a655d52ef130f8acb02f8ed33a Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-13 17:24:52 +00:00
"${_Qt_NOTFOUND_MESSAGE}Failed to find required Qt component \"${module}\". ${_qt_component_not_found_msg}")
CMake: Suggest hints on how to debug missing packages Depending on CMake version suggest usage of either --debug-find-pkg or CMAKE_FIND_DEBUG_MODE to help troubleshoot why dependent packages are not found. To achieve that, append the hint message to the _NOT_FOUND_MESSAGE. To ensure it works for qt dependencies, and not only tool and 3rd party dependencies, _qt_internal_find_qt_dependencies is modified to set variable names infixed by the target name, so the name is consistent with the other dependency lookup functions. The check and message are also added when a Qt6 component is not found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I4ef23d1c53ac8e04eb72c260d6860c1eeec8d7a3 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-14 13:28:12 +00:00
set(_qt_full_component_name "@INSTALL_CMAKE_NAMESPACE@${module}")
CMake: Introduce QT_DEBUG_FIND_PACKAGE for troubleshooting When a Qt component or dependency is not found, we will now show a message that the user can reconfigure the project with -DQT_DEBUG_FIND_PACKAGE=ON. If the option is enabled, various variables that find_package uses to find packages (like CMAKE_PREFIX_PATH, CMAKE_FIND_ROOT_PATH) will be recorded before each find_package / find_dependency call that is executed in any of the Qt package files. If any find_package call fails (a package has its _FOUND variable set to 0), the values of all those recorded variables will be shown. This is useful to troubleshoot issues, especially when cross-compiling, without having to manually modify the various Config files. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I3654960597911bd704fbe3c419bcae347ab739a9 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-14 15:00:56 +00:00
_qt_internal_suggest_dependency_debugging(${_qt_full_component_name}
_qt_full_component_name _Qt_NOTFOUND_MESSAGE)
CMake: Suggest hints on how to debug missing packages Depending on CMake version suggest usage of either --debug-find-pkg or CMAKE_FIND_DEBUG_MODE to help troubleshoot why dependent packages are not found. To achieve that, append the hint message to the _NOT_FOUND_MESSAGE. To ensure it works for qt dependencies, and not only tool and 3rd party dependencies, _qt_internal_find_qt_dependencies is modified to set variable names infixed by the target name, so the name is consistent with the other dependency lookup functions. The check and message are also added when a Qt6 component is not found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I4ef23d1c53ac8e04eb72c260d6860c1eeec8d7a3 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-14 13:28:12 +00:00
unset(_qt_full_component_name)
CMake: Don't search for next Qt component if a required one is missing If a project calls find_package(Qt6 COMPONENTS Gui Network) and Gui is not found, there's no reason to look for Network, because the COMPONENTS option implies that it is a required component. Failing to find a component sets Qt6_FOUND to false, so we can break early. If a project calls find_package(Qt6 OPTIONAL_COMPONENTS Gui Network) then Network will still be looked for if Gui is not found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I5c5edd27729635e6b7ade059656b49320364ad13 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-13 16:11:54 +00:00
break()
QtConfig.cmake.in: Fix typo This var needs the cmake namespace as prefix. Follow-up commit of c5e2838b642d2a50d951efe7b582d9261d55dfb7 Change-Id: I595306301313b1ff911134776480d28b3194bcf8 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
2019-06-03 18:47:37 +00:00
elseif(NOT @INSTALL_CMAKE_NAMESPACE@_FIND_QUIETLY)
CMake: Improve component / package not found error messages Provide better error messages when a Qt package / component is not found. Mention the location of the expected Config file on the file system, whether it exists Also mention the location of the Config file that was specified by the user when configuring the project or which CMake computed and stored in QtModule_DIR cache var. Mention that a package is not found in case if the main target exposed by that package is not found. If the target is not found, mention that it might be due to QT_NO_CREATE_TARGETS being set to TRUE (when it is set to true). If it is set to true, the assumption is that the target must have been defined by something else before the find_package call (either an earlier find_package call without QT_NO_CREATE_TARGETS set to TRUE or maybe it's the use case of Qt being built together with its examples or it's a super build). Unset _Qt_NOTFOUND_MESSAGE to ensure that the Qt6 not found error message is not spilled into any subsequent find_package(Qt6) calls, causing a cascade of unwarranted warnings / errors. Make sure to unset it only if components were specified, so the message is not shown or unset in any of the recursive find_package(Qt6) calls which is a dependency for regular Qt module packages. This works fine, because find_package(Qt6) calls with components are only done in project code and not done by the transitive dependency code (which looks for Qt6Foo packages directly). Remove some dead code. Pick-to: 6.2 Task-number: QTBUG-95532 Change-Id: Ie93d18e25e33aa0fe9e9da9a60e3d3e4cd6adb58 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-02 14:02:04 +00:00
message(WARNING
CMake: Clarify if an optional or required Qt component is not found Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: Id35f128404eb49a655d52ef130f8acb02f8ed33a Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-13 17:24:52 +00:00
"Failed to find optional Qt component \"${module}\". ${_qt_component_not_found_msg}")
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
endif()
CMake: Improve component / package not found error messages Provide better error messages when a Qt package / component is not found. Mention the location of the expected Config file on the file system, whether it exists Also mention the location of the Config file that was specified by the user when configuring the project or which CMake computed and stored in QtModule_DIR cache var. Mention that a package is not found in case if the main target exposed by that package is not found. If the target is not found, mention that it might be due to QT_NO_CREATE_TARGETS being set to TRUE (when it is set to true). If it is set to true, the assumption is that the target must have been defined by something else before the find_package call (either an earlier find_package call without QT_NO_CREATE_TARGETS set to TRUE or maybe it's the use case of Qt being built together with its examples or it's a super build). Unset _Qt_NOTFOUND_MESSAGE to ensure that the Qt6 not found error message is not spilled into any subsequent find_package(Qt6) calls, causing a cascade of unwarranted warnings / errors. Make sure to unset it only if components were specified, so the message is not shown or unset in any of the recursive find_package(Qt6) calls which is a dependency for regular Qt module packages. This works fine, because find_package(Qt6) calls with components are only done in project code and not done by the transitive dependency code (which looks for Qt6Foo packages directly). Remove some dead code. Pick-to: 6.2 Task-number: QTBUG-95532 Change-Id: Ie93d18e25e33aa0fe9e9da9a60e3d3e4cd6adb58 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-02 14:02:04 +00:00
unset(_qt_expected_component_config_path)
unset(_qt_expected_component_dir_path)
unset(_qt_candidate_component_dir_path)
unset(_qt_component_not_found_msg)
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
endif()
endforeach()
CMake: Improve component / package not found error messages Provide better error messages when a Qt package / component is not found. Mention the location of the expected Config file on the file system, whether it exists Also mention the location of the Config file that was specified by the user when configuring the project or which CMake computed and stored in QtModule_DIR cache var. Mention that a package is not found in case if the main target exposed by that package is not found. If the target is not found, mention that it might be due to QT_NO_CREATE_TARGETS being set to TRUE (when it is set to true). If it is set to true, the assumption is that the target must have been defined by something else before the find_package call (either an earlier find_package call without QT_NO_CREATE_TARGETS set to TRUE or maybe it's the use case of Qt being built together with its examples or it's a super build). Unset _Qt_NOTFOUND_MESSAGE to ensure that the Qt6 not found error message is not spilled into any subsequent find_package(Qt6) calls, causing a cascade of unwarranted warnings / errors. Make sure to unset it only if components were specified, so the message is not shown or unset in any of the recursive find_package(Qt6) calls which is a dependency for regular Qt module packages. This works fine, because find_package(Qt6) calls with components are only done in project code and not done by the transitive dependency code (which looks for Qt6Foo packages directly). Remove some dead code. Pick-to: 6.2 Task-number: QTBUG-95532 Change-Id: Ie93d18e25e33aa0fe9e9da9a60e3d3e4cd6adb58 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-02 14:02:04 +00:00
if(@INSTALL_CMAKE_NAMESPACE@_FIND_COMPONENTS AND _Qt_NOTFOUND_MESSAGE)
cmake: Make find_package(Qt5 ...) work properly Introduce a new cached variable INSTALL_CMAKE_NAMESPACE for defining the prefix used for CMake config files (c.f. "${PREFIX}Core/${PREFIX}CoreConfig.cmake") Also make sure to `find_dependency(...)` the required packages inside the individual CMake config files. I.e. in Qt5WidgetsConfig.cmake, search for Qt5Core, etc. pp.. Change-Id: Idc027925fe9d5323091c4853803ad5ce44b1afc6 Reviewed-by: Jean-Michaël Celerier <jean-michael.celerier@kdab.com> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-02-11 10:34:35 +00:00
set(@INSTALL_CMAKE_NAMESPACE@_NOT_FOUND_MESSAGE "${_Qt_NOTFOUND_MESSAGE}")
CMake: Improve component / package not found error messages Provide better error messages when a Qt package / component is not found. Mention the location of the expected Config file on the file system, whether it exists Also mention the location of the Config file that was specified by the user when configuring the project or which CMake computed and stored in QtModule_DIR cache var. Mention that a package is not found in case if the main target exposed by that package is not found. If the target is not found, mention that it might be due to QT_NO_CREATE_TARGETS being set to TRUE (when it is set to true). If it is set to true, the assumption is that the target must have been defined by something else before the find_package call (either an earlier find_package call without QT_NO_CREATE_TARGETS set to TRUE or maybe it's the use case of Qt being built together with its examples or it's a super build). Unset _Qt_NOTFOUND_MESSAGE to ensure that the Qt6 not found error message is not spilled into any subsequent find_package(Qt6) calls, causing a cascade of unwarranted warnings / errors. Make sure to unset it only if components were specified, so the message is not shown or unset in any of the recursive find_package(Qt6) calls which is a dependency for regular Qt module packages. This works fine, because find_package(Qt6) calls with components are only done in project code and not done by the transitive dependency code (which looks for Qt6Foo packages directly). Remove some dead code. Pick-to: 6.2 Task-number: QTBUG-95532 Change-Id: Ie93d18e25e33aa0fe9e9da9a60e3d3e4cd6adb58 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-02 14:02:04 +00:00
unset(_Qt_NOTFOUND_MESSAGE)
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
endif()
CMake: Promote all targets to global within a scope when possible CMake 3.21 introduced a new IMPORTED_TARGETS directory property which we can use to promote all imported targets within a scope to be global. This would cover transitive non-Qt imported targets which the Qt build system does not know about and is thus a more complete solution compared to promoting only Qt targets. Run a finalizer at the end of the directory scope where find_package(Qt6) is called to promote all imported targets within that scope to global (when requested). The old promotion method is disabled when the CMake version is new enough. Pick-to: 6.2 Task-number: QTBUG-92878 Task-number: QTBUG-94528 Change-Id: I533a3bd4186eba652f878ddd72c76118c2fd8bae Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-11 07:54:47 +00:00
__qt_internal_defer_promote_targets_in_dir_scope_to_global()
Use target_link_options to propagate object libraries target_link_options are placed by CMake at the beginning of a linker line. This gives us an opportunity to use the function to propagate object libraries. This change adds one more check in the root Config.cmake file. If CMP0099 policy is enabled, CMake enables propagating of the linking options when linking two static libraries using the PRIVATE linking visibility, so we can rely on the correct linking order and expect object libraries to be propagated. Note that on the platforms where cmake version is higher than 3.16 Qt uses CMP0099 NEW in functions like qt_add_executable. This means that at the moment of creating an executable target the TARGET_POLICY genex will also be NEW, so we do not take into the account the user defined CMP0099. If the CMP0099 policy is not available for a certain CMake version we skip the TARGET_POLICY check and simply disable propagation of the object libraries using target_link_options for both user and Qt libraries. This is applicable for the CMake versions 3.16 and less. Linking approaches have the following priorities(from higher to lower) after this change: - target_link_libraries - works if link order matters not or CMake version greater equal 3.21. - target_link_options - works if CMP0099 is set to NEW by user or if the CMake version is greater than or equal to 3.17 and an executable is created using Qt functions. - object library finalizer - works if CMake version is greater equal 3.19 or qt6_finalize_target is called explicitly. - target_sources - is used when all the other approaches could not be used. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Amends 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Change-Id: I14f88caeb04e357191c840abeab89b03e210b796 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-29 16:00:39 +00:00
if(CMAKE_VERSION VERSION_LESS 3.21)
__qt_internal_check_link_order_matters()
__qt_internal_check_cmp0099_available()
endif()
Reference in New Issue Copy Permalink