qiurui
/
qtbase
mirror of https://github.com/qt/qtbase.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
qtbase/cmake/QtConfig.cmake.in

271 lines
12 KiB
CMake
Raw Permalink Normal View History

Change license for .in files According to QUIP-18 [1], all build system files should be BSD-3-Clause. The files in this patch are part of the build system. [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: Ibc6a60a9b009fab0c953e8e3269533c121e4511e Reviewed-by: Kai Köhne <kai.koehne@qt.io>
2024-02-20 08:45:50 +00:00
# Copyright (C) 2024 The Qt Company Ltd.
# SPDX-License-Identifier: BSD-3-Clause
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: Adjust CMP0156 policy handling for Apple platforms Backstory. 1) Starting with Qt 6.8, the prebuilt Qt for iOS SDK is built as static framework bundles instead of static libraries. That is done so that we can embed a privacy manifest into each framework bundle. 2) Up until CMake 3.28, CMake would not attempt to de-duplicate static libraries (or frameworks) on the command line. Starting with CMake 3.29, the CMP0156 policy was introduced to allow such de-duplication. 3) Since a while ago, Qt had its own policy handling for CMP0156, which it force sets to OLD, to disable any de-duplication. That was done to avoid possible regressions on platforms where link order matters. 4) A developer might add the -ObjC linker flag to a project, to ensure the linker retains all Objective-C categories it encounters in all the static libraries that were provided on the link line. Retaining in this case means that the /whole/ object file of a static library will be linked to the final executable. 5) The Apple ld linker (both the legacy and the new ld_prime one) can't cope with duplicate static frameworks on the link line when the -ObjC flag is used. It ends up throwing duplicate symbol errors, from trying to link the same object file from the same static framework more than once. The linker works just fine if the link line contains duplicate static libraries, rather than static frameworks. 6) When a project links against Qt6::Gui and Qt6::Core, the link line will contain Qt6::Core twice. This gets even more involved, when linking plugins, which cause static framework cycles, and thus a framework might appear multiple times. Thus, we have the situation that Qt forces the CMP0156 policy to OLD, Qt6::Core appears multiple times on the link line, no de-duplication is performed, the project adds the -ObjC flag, and the linker throws duplicate symbol errors. We can fix this by force setting the CMP0156 policy to NEW when targeting Apple platforms and using CMake 3.29+. A potential workaround for a project developer is to set the policy to NEW manually in their project. Unfortunately that doesn't work for older Qt versions. That's because CMake applies the policy value when add_executable is called, and the policy value in qt_add_executable is the one that is recorded when the function is defined. And the recorded policy is always OLD, because Qt6Config.cmake calls cmake_minimum_required with VERSION up to 3.21, which resets the policy value to OLD. So we have to force set the policy in qt_add_executable / qt_add_library via the existing __qt_internal_set_cmp0156 function. The __qt_internal_set_cmp0156 had some diagnostics to show a warning when the user modifies the policy themselves, but this never worked because of reason stated above: the policy value was always overridden in Qt6Config.cmake. To actually make the diagnostic work, there is now new code to save the policy value in the current directory scope, before Qt resets it. This only works if a project uses the find_package(Qt6 COMPONENTS Foo) signature. It won't work with a find_package(Qt6Core)-like signature. The policy value is not modified for platforms other than Apple ones for now. Amends 9702c3c78b2c16db6a9d0515d7d7698d9b064cd8 Pick-to: 6.5 6.8 6.9 Fixes: QTBUG-135978 Change-Id: I4d6e6c2a01e7092b417fc669d2aea40cf2dca578 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-05-05 15:18:49 +00:00
# This is included before the cmake_minimum_required on purpose.
include("${CMAKE_CURRENT_LIST_DIR}/QtPublicCMakeEarlyPolicyHelpers.cmake")
__qt_internal_save_directory_scope_policy_cmp0156()
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")
"Simplify" versionless targets Versionless targets in Qt6 are interface libraries that link the versioned libraries using the INTERFACE link type. This makes the linking chain more complicated than it can be. Also we miss some significant interface properties in the versionless targets comparing to the versioned targets. The new approach manually generates the versionless targets, instead of using CMake exports. For CMake versions < 3.18 we now create a copy of the versioned targets. The copy includes all the relevant INTERFACE properties from the versioned targets and imported locations for all configs. For CMake versions >= 3.18 we now create the versionless target ALIASes which should behave give the transparent access to the versioned targets. Using the QT_USE_OLD_VERSION_LESS_TARGETS flag you may force the behavor of the CMake versions <= 3.18 The change is partial workaround for QTBUG-86533. Task-number: QTBUG-114706 Change-Id: Iafadf6154eb4912df0697648c031fcc1cbde04e0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-01-24 15:12:19 +00:00
include("${CMAKE_CURRENT_LIST_DIR}/QtPublicCMakeHelpers.cmake")
Move QtInstallPaths.cmake to the Qt6 package QtInstallPaths needs to be loaded at early stages Change-Id: Ie275ad2a8855b7555b110c35814ebadafe1817c6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-03-20 11:43:37 +00:00
include("${CMAKE_CURRENT_LIST_DIR}/QtInstallPaths.cmake")
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
__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
Replace `QT_NO_CREATE_TARGETS` with an automated and scoped logic Effectively check if we are importing while still building the current project Task-number: QTBUG-135233 Change-Id: If172617463157e84e1b16fc2354147fabae41084 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-03-05 10:27:25 +00:00
# Do the checks inside Targets.cmake even when the file is still being generated
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@TargetsPrecheck.cmake")
# Create the targets unless we are generating the @INSTALL_CMAKE_NAMESPACE@Targets.cmake
if(NOT __qt_skip_include_targets_file)
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
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)
"Simplify" versionless targets Versionless targets in Qt6 are interface libraries that link the versioned libraries using the INTERFACE link type. This makes the linking chain more complicated than it can be. Also we miss some significant interface properties in the versionless targets comparing to the versioned targets. The new approach manually generates the versionless targets, instead of using CMake exports. For CMake versions < 3.18 we now create a copy of the versioned targets. The copy includes all the relevant INTERFACE properties from the versioned targets and imported locations for all configs. For CMake versions >= 3.18 we now create the versionless target ALIASes which should behave give the transparent access to the versioned targets. Using the QT_USE_OLD_VERSION_LESS_TARGETS flag you may force the behavor of the CMake versions <= 3.18 The change is partial workaround for QTBUG-86533. Task-number: QTBUG-114706 Change-Id: Iafadf6154eb4912df0697648c031fcc1cbde04e0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-01-24 15:12:19 +00:00
if(CMAKE_VERSION VERSION_LESS 3.18 OR QT_USE_OLD_VERSION_LESS_TARGETS)
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@VersionlessTargets.cmake")
else()
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@VersionlessAliasTargets.cmake")
endif()
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
endif()
Replace `QT_NO_CREATE_TARGETS` with an automated and scoped logic Effectively check if we are importing while still building the current project Task-number: QTBUG-135233 Change-Id: If172617463157e84e1b16fc2354147fabae41084 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-03-05 10:27:25 +00:00
set(__qt_targets_file_included ON)
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
Attempt checking the CMAKE_GENERATOR when passing hardening flags Use the _qt_internal_cmake_generator of the PlatformCommonInternal to store the current CMake generator is used. The property allows checking the CMake generator as part of transitively propagated properties, like those we use in PlatformCommonInternal. Wrap the compile definisions belonging to libcpp_hardening feature with CMake generator check, since Xcode sets own definitions which lead to the macro 'redefinition' compilation warning. Change-Id: I5f6131245746afbe413efc831a9447ba40142a4e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-09-24 13:20:00 +00:00
if(TARGET @INSTALL_CMAKE_NAMESPACE@::PlatformCommonInternal)
get_target_property(_qt_platform_internal_common_target
@INSTALL_CMAKE_NAMESPACE@::PlatformCommonInternal ALIASED_TARGET)
if(NOT _qt_platform_internal_common_target)
set(_qt_platform_internal_common_target @INSTALL_CMAKE_NAMESPACE@::PlatformCommonInternal)
endif()
Make `qt_internal_set_warnings_are_errors_flags` genex-ed Fixes: QTBUG-132705 Change-Id: I57987f1ae1c6d6adc4a2d0151f365c24605b940e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-24 16:27:25 +00:00
set(_qt_internal_clang_msvc_frontend FALSE)
if(CMAKE_CXX_COMPILER_ID STREQUAL "Clang" AND
CMAKE_CXX_COMPILER_FRONTEND_VARIANT STREQUAL "MSVC")
set(_qt_internal_clang_msvc_frontend TRUE)
endif()
Attempt checking the CMAKE_GENERATOR when passing hardening flags Use the _qt_internal_cmake_generator of the PlatformCommonInternal to store the current CMake generator is used. The property allows checking the CMake generator as part of transitively propagated properties, like those we use in PlatformCommonInternal. Wrap the compile definisions belonging to libcpp_hardening feature with CMake generator check, since Xcode sets own definitions which lead to the macro 'redefinition' compilation warning. Change-Id: I5f6131245746afbe413efc831a9447ba40142a4e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-09-24 13:20:00 +00:00
set_target_properties(${_qt_platform_internal_common_target}
PROPERTIES
_qt_internal_cmake_generator "${CMAKE_GENERATOR}"
Make `qt_internal_set_warnings_are_errors_flags` genex-ed Fixes: QTBUG-132705 Change-Id: I57987f1ae1c6d6adc4a2d0151f365c24605b940e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-24 16:27:25 +00:00
_qt_internal_clang_msvc_frontend "${_qt_internal_clang_msvc_frontend}"
Attempt checking the CMAKE_GENERATOR when passing hardening flags Use the _qt_internal_cmake_generator of the PlatformCommonInternal to store the current CMake generator is used. The property allows checking the CMake generator as part of transitively propagated properties, like those we use in PlatformCommonInternal. Wrap the compile definisions belonging to libcpp_hardening feature with CMake generator check, since Xcode sets own definitions which lead to the macro 'redefinition' compilation warning. Change-Id: I5f6131245746afbe413efc831a9447ba40142a4e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-09-24 13:20:00 +00:00
)
unset(_qt_platform_internal_common_target)
endif()
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: Copy template Info.plist for macOS manually, like we do for iOS Unifies the approach between iOS and macOS. By copying the Info.plist to the build directory, we also open up the possibility to modify it, which we can't do when CMake does the copy during its generator step. Change-Id: I59f9f69ac368166bb26d8a5c57bf4ea3f503d51b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-04-20 10:13:09 +00:00
if(APPLE)
if(NOT CMAKE_SYSTEM_NAME OR CMAKE_SYSTEM_NAME STREQUAL "Darwin")
set(__qt_internal_cmake_apple_support_files_path "${_qt_import_prefix}/macos")
elseif(CMAKE_SYSTEM_NAME STREQUAL "iOS")
set(__qt_internal_cmake_apple_support_files_path "${_qt_import_prefix}/ios")
Add preliminary support for Qt for visionOS Qt already runs on Vision Pro as "Designed for iPad", using Qt for iOS. This change enables building Qt for visionOS directly, which opens the door to visionOS specific APIs and use-cases such as volumes and immersive spaces. The platform removes some APIs we depend on, notably UIScreen, so some code paths have been disabled or mocked to get something up and running. As our current window management approach on UIKit platforms depends on UIWindow and UIScreen there is currently no way to bring up QWindows. This will improve once we refactor our window management to use window scenes. To configure for visionOS, pass -platform macx-visionos-clang, and optionally add -sdk xrsimulator to build for the simulator. Change-Id: I4eda55fc3fd06e12d30a188928487cf68940ee07 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-18 18:35:52 +00:00
elseif(CMAKE_SYSTEM_NAME STREQUAL "visionOS")
set(__qt_internal_cmake_apple_support_files_path "${_qt_import_prefix}/visionos")
cmake: Copy template Info.plist for macOS manually, like we do for iOS Unifies the approach between iOS and macOS. By copying the Info.plist to the build directory, we also open up the possibility to modify it, which we can't do when CMake does the copy during its generator step. Change-Id: I59f9f69ac368166bb26d8a5c57bf4ea3f503d51b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-04-20 10:13:09 +00:00
endif()
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: 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.
CMake: Dynamically include and install Helpers and other files Instead of duplicating file names that need to be include()'ed in two different places if the files are meant to be used in both Qt builds and public user projects and then also mention the name when installing, extract the file names into lists returned by functions. Call these functions where needed to iteratively include() the files as well as install them, without having to remember updating multiple code locations. The new functions return the following list of file names: - upstream cmake modules that need to be included during a Qt build - public (Qt build and user project) cmake helpers that need to be included and installed - private (Qt build only) cmake helpers that need to be included and installed - public files that need to be installed, but not included - private files that need to be installed, but not included We also generate the list of public files to include in Qt6Config.cmake. Task-number: QTBUG-86035 Change-Id: I1e7287f4e1d041c723f144ba9626b34f873c4891 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-11-17 16:47:04 +00:00
set(__qt_public_files_to_include
@QT_PUBLIC_FILES_TO_INCLUDE@
)
foreach(__qt_public_file_to_include IN LISTS __qt_public_files_to_include)
include("${__qt_public_file_to_include}")
endforeach()
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
Consider INSTALL_LIBDIR when calculating various cmake paths Task-number: QTBUG-123039 Change-Id: I111cd612afe64a4f8456ab05d6ff3caf828c4712 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2024-03-20 08:45:48 +00:00
if(NOT DEFINED QT_CMAKE_EXPORT_NAMESPACE)
set(QT_CMAKE_EXPORT_NAMESPACE @QT_CMAKE_EXPORT_NAMESPACE@)
endif()
CMake: Move __qt_internal_collect_additional_prefix_paths Move it out of QtConfig.cmake.in into QtPublicCMakeHelpers.cmake so that the Qt6Config file is less cluttered. Pick-to: 6.4 Change-Id: I772a0cca35d5c03cd688c3f1de34984484444105 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-09-13 15:27:42 +00:00
set(QT_ADDITIONAL_PACKAGES_PREFIX_PATH "" CACHE STRING
"Additional directories where find(Qt6 ...) components are searched")
set(QT_ADDITIONAL_HOST_PACKAGES_PREFIX_PATH "" CACHE STRING
"Additional directories where find(Qt6 ...) host Qt components are searched")
__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)
CMake: Move __qt_internal_prefix_paths_to_roots Move it into QtPublicCMakeHelpers.cmake so it is available also when configuring qtbase and the Qt6Config.cmake file is not yet loaded. Pick-to: 6.4 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I88127fe0439ae26af1d125eb584244d315574a48 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-09-13 15:23:55 +00:00
__qt_internal_prefix_paths_to_roots(_qt_additional_host_packages_root_paths
"${_qt_additional_host_packages_prefix_paths}")
Collect CMAKE_MODULE_PATH from QT_ADDITIONAL_PACKAGES_PREFIX_PATH This is sensitive for the 'include' calls that expect cmake scripts to be found in some staging prefixes. In yocto QT_ADDITIONAL_PACKAGES_PREFIX_PATH points to the package image path(installation snapshot). If repo provides bundled 3rdparties the 'include' statement that includes 'FindWrap<3rdparty>ConfigExtra' is unnable to locate it, since it's expected to be found in Qt installation, but the file didn't land there at ptest stage. Fixes: QTBUG-122205 Pick-to: 6.5 6.6 6.7 Change-Id: Idd03f44efd2e3fdaa476873068c73ac28cd0a7b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-02-29 07:10:31 +00:00
__qt_internal_collect_additional_module_paths()
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: Workaround Android CMP0155 issue If a user: - targets Android - sets cmake_minimum_required(3.29) in their project which implies policy CMP0155 being set to NEW - sets CMAKE_CXX_STANDARD >= 20 - uses Qt Creator's maintenance tool provider - uses Qt Creator's default of ANDROID_USE_LEGACY_TOOLCHAIN_FILE=OFF then they will hit an issue where the Threads package cannot be found due to a CMake bug that causes all try_compile calls to fail, which in turns causes the Qt6 package not being found. Android and ANDROID_USE_LEGACY_TOOLCHAIN_FILE being OFF is relevant, because in that case CMake fails to find the CMAKE_CXX_COMPILER_CLANG_SCAN_DEPS tool, which is used during try_compile builds. CMP0155 set to NEW and CMAKE_CXX_STANDARD >= 20 is relevant, because only in that case will CMake try to use the scan deps tool to scan for modules during try_compile builds. The maintenance tool provider is relevant in this case, because CMake records the CMP0155 policy value at function definition time. Normally without a dependency provider, the policy value at Threads package lookup time would be OLD because each Qt6Config.cmake file has a cmake_minimum_required(3.16..3.21) call which overrides any other policy value. But because the dependency provider function is defined before any of Qt's code is loaded, it inherits the CMP0155 NEW from cmake_minimum_required(3.29) of the user's project. That causes all find_package lookups to use CMP0155=NEW, ignoring Qt's request. This works by design from CMake's PoV, but causes unfortunate fallout in this case. Because we can't influence the recorded policy value of the provided function from the outside in any way, the only thing we can do is disable module scanning via CMAKE_CXX_SCAN_FOR_MODULES. Work around the issue by setting CMAKE_CXX_SCAN_FOR_MODULES to OFF inside Qt6Config.cmake, which will set it in the directory scope of the find_package(Qt6) caller, affecting all try_compile calls there. Do it only in the specific conditions mentioned above. Allow opting out of the variable assignment by configuring with -DQT_NO_SET_CMAKE_CXX_SCAN_FOR_MODULES_TO_OFF=ON Doing this in Qt6Config.cmake allows working around the issue when using older Creator versions that don't work around it themselves, See https://gitlab.kitware.com/cmake/cmake/-/issues/27169 Pick-to: 6.8 6.9 6.10 Fixes: QTBUG-139439 Change-Id: Id171c88566c41b65b24c2f2a3874e3f3c0abc814 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-08-28 14:48:37 +00:00
@QT_CONFIG_EXTRA_CODE_BEFORE_DEPENDENCIES@
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: Provide a way to find all available Qt module packages A project might want to find_package all available (installed) Qt CMake packages that contain qt modules. A use case might be a qml app that needs to link to all of Qt, and support showing qml files that can load any Qt qml module. Add a new Qt6 COMPONENT called ALL_QT_MODULES. It can be used like this: find_package(Qt6 COMPONENTS ALL_QT_MODULES). The implementation will find all installed Qt modules by globbing over all json files installed in $qt/modules dir, and treat the file names as package names. It will then tell Qt6 to find_package each of those packages. Pick-to: 6.8 6.9 Change-Id: I89242307438576a0cbb3cdca80a9cb72818b6035 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2025-01-23 18:29:17 +00:00
set(__qt_umbrella_find_components ${@INSTALL_CMAKE_NAMESPACE@_FIND_COMPONENTS})
__qt_internal_handle_find_all_qt_module_packages(__qt_umbrella_find_components
COMPONENTS ${__qt_umbrella_find_components}
)
foreach(module ${__qt_umbrella_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
Avoid using the PROJECT_VERSION when accessing the HostInfo package variables The related functionality meant to be enabled by BuildInternals, which makes the lookup of the pre-defined HostInfo version based on either calculated or pre-defined INSTALL_CMAKE_NAMESPACE. The PROJECT_VESION(_MAJOR) meanwhile is hardcoded by the current Qt repo, which is not necessary aligned with BuildInternals/HostInfo. Pick-to: 6.5 6.8 6.9 Change-Id: I61052c93ce2d6ee3c6d8025da2e078edcde48d0d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-03-17 16:54:32 +00:00
"${@INSTALL_CMAKE_NAMESPACE@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: Silence the private module warning for dependencies If a private module package is pulled in by another Qt module we showed the private module warning message. The user couldn't act on the warning other than disabling it completely. This doesn't seem useful. Now, we only show the warning if the user explicitly does find_package(Qt6FooPrivate). There's the situation where a private module is pulled in as dependency and later pulled in by the user. For example, in a static Linux build find_package(Qt6 REQUIRED COMPONENTS Gui CorePrivate) will pull in CorePrivate as transitive dependency of Gui's plugins. To still see a warning for CorePrivate in this case we need to trigger the warning in Qt6Config.cmake when handling the COMPONENTS. To achieve that, the warning code has been moved to a function which is called in Qt6Config.cmake and Qt6FooPrivateConfig.cmake Task-number: QTBUG-87776 Change-Id: Ie9cc2d287d1fcb94db77045165f703cebcb6983d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-29 07:50:17 +00:00
if(@INSTALL_CMAKE_NAMESPACE@${module}_FOUND)
CMake: Fix getting target property from Tools-only packages A call to find_package(Qt6 COMPONENTS LinguistTools) would fail with CMake Error at Qt6Config.cmake:212 (get_target_property): get_target_property() called with non-existent target "Qt6::LinguistTools". Tools packages don't have a module, guard the get_target_property call. Amends a9c18e5df240ce4a8bdc4dd3e7b8d5289227d2d9 Change-Id: Idb70b427d0762ed64c2ef77133a2ae56f310483d Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2025-02-17 09:17:43 +00:00
# Tools packages don't usually provide a qt module, so there's no target.
if(TARGET @INSTALL_CMAKE_NAMESPACE@::${module})
get_target_property(__qt_${module}_is_private @INSTALL_CMAKE_NAMESPACE@::${module}
_qt_is_private_module
)
if(__qt_${module}_is_private)
_qt_internal_show_private_module_warning(${module})
endif()
unset(__qt_${module}_is_private)
CMake: Silence the private module warning for dependencies If a private module package is pulled in by another Qt module we showed the private module warning message. The user couldn't act on the warning other than disabling it completely. This doesn't seem useful. Now, we only show the warning if the user explicitly does find_package(Qt6FooPrivate). There's the situation where a private module is pulled in as dependency and later pulled in by the user. For example, in a static Linux build find_package(Qt6 REQUIRED COMPONENTS Gui CorePrivate) will pull in CorePrivate as transitive dependency of Gui's plugins. To still see a warning for CorePrivate in this case we need to trigger the warning in Qt6Config.cmake when handling the COMPONENTS. To achieve that, the warning code has been moved to a function which is called in Qt6Config.cmake and Qt6FooPrivateConfig.cmake Task-number: QTBUG-87776 Change-Id: Ie9cc2d287d1fcb94db77045165f703cebcb6983d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-29 07:50:17 +00:00
endif()
else()
CMake: Don't look for Qt6 components that are already found This matches what we do in Dependencies.cmake files, except this time for COMPONENTS passed to the Qt6 package. For example if a project does find_package(Qt6 COMPONENTS Widgets Core) we'd end up looking for Core twice. Once as a dependency of Widgets and once as a standalone request of the project. Make sure to skip the second lookup if it was already found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I61db7fbb99818b4b70a0bfe3e167b6f14732292e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 16:37:04 +00:00
find_package(@INSTALL_CMAKE_NAMESPACE@${module}
${@INSTALL_CMAKE_NAMESPACE@_FIND_VERSION}
${_@INSTALL_CMAKE_NAMESPACE@_FIND_PARTS_QUIET}
PATHS
Make sure that tests use the module build directory but not install path If we configure module that is already installed it's expected that tests use the build directory to resolve all the depdencies, but not the install directory. This is especially sensetive if the module cmake scripts were changed. This changes the order of find_<package|dependency> PATHS that are used to locate Qt package. QT_EXAMPLES_CMAKE_PREFIX_PATH now is used at first, so we guarantee that we look into the build directory at first place. This trick only works if build directory is added to CMAKE_FIND_ROOT_PATH. The reason for that is the internal CMake logic that tries to relocate the search PATHs and put the paths that are subdirs of or exact CMAKE_FIND_ROOT_PATH higher in search list. Fixes: QTBUG-115730 Change-Id: Icab721f0a6eac7301c626350ab214cc4545b368b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-08-22 17:11:30 +00:00
${QT_BUILD_CMAKE_PREFIX_PATH}
CMake: Don't look for Qt6 components that are already found This matches what we do in Dependencies.cmake files, except this time for COMPONENTS passed to the Qt6 package. For example if a project does find_package(Qt6 COMPONENTS Widgets Core) we'd end up looking for Core twice. Once as a dependency of Widgets and once as a standalone request of the project. Make sure to skip the second lookup if it was already found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I61db7fbb99818b4b70a0bfe3e167b6f14732292e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 16:37:04 +00:00
${_qt_cmake_dir}
${_qt_additional_packages_prefix_paths}
${__qt_find_package_host_qt_path}
${_qt_additional_host_packages_prefix_paths}
${__qt_use_no_default_path_for_qt_packages}
)
endif()
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
CMake: Fix install destination of in-tree examples Previously we called _qt_internal_override_example_install_dir_to_dot in Qt6CoreConfigExtras.cmake as part of a find_package(Qt6 COMPONENTS Core) call, and we assumed that the Extras file would always be included in each example project. But our package dependencies handling code skips calling find_package(Qt6Core) if Qt6Core_FOUND is already set to TRUE, which will definitely happen due to root-scope find_package calls when configuring other repos. That means we wouldn't override INSTALL_EXAMPLEDIR to "." and the install destination would end up being something like ${CMAKE_INSTALL_PREFIX}/example_relative_path/example_relative_path aka a double nested path. Make sure we call the _qt_internal_override_example_install_dir_to_dot function in Qt6ConfigConfig.cmake in addition to Qt6CoreConfig.cmake. That way, even if Qt6Core is skipped during dependency resolution, it's still handled by the Qt6 package itself. Because the function is defined in the Core package, guard the call with an if(COMMAND) and only call the function if it wasn't previously called within the current or ancestor scopes. Amends ac4a913f333561803003650817de453f43be924d Pick-to: 6.2 6.3 6.4 Fixes: QTBUG-102879 Change-Id: Id47e3ce06faec6d156ae1473942dae0f9b90cb46 Reviewed-by: Christophe Giboudeaux <christophe@krop.fr> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-26 13:51:02 +00:00
if(@INSTALL_CMAKE_NAMESPACE@_FOUND
AND COMMAND _qt_internal_override_example_install_dir_to_dot
AND NOT _qt_internal_example_dir_set_to_dot)
_qt_internal_override_example_install_dir_to_dot()
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()