summaryrefslogtreecommitdiffstats
path: root/cmake/QtConfig.cmake.in
Commit message (Collapse)AuthorAgeFilesLines
* Fix QT_ADDITIONAL_(HOST_)PACKAGES_PREFIX_PATH environment variablesJoerg Bornemann2022-02-231-1/+5
| | | | | | | | | | | | | | | | | 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>
* CMake: Add default launch screen storyboard for iOS appsAlexandru Croitor2022-02-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Introduce QT_ADDITIONAL_HOST_PACKAGES_PREFIX_PATHJoerg Bornemann2022-02-151-21/+51
| | | | | | | | | | | | 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>
* Use 'copy' but not 'copy_if_different' on Windows platformsAlexey Edelev2022-02-101-0/+1
| | | | | | | | | | | | | | 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>
* Use IMPORTED_LOCATION of rcc targetAlexey Edelev2022-02-011-0/+1
| | | | | | | | | | | 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>
* CMake: Fix host UiTools being picked up instead of target oneAlexandru Croitor2022-01-271-0/+1
| | | | | | | Pick-to: 6.2 6.3 Fixes: QTBUG-100233 Change-Id: Id4b30841ba9e499f462325f882218edf407e0a00 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Use Qt6HostInfo dir for Tools CMAKE_PREFIX_PATH assignmentAlexandru Croitor2021-10-291-1/+2
| | | | | | | | | | | | 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>
* Revert "CMake: Warn if cmake_minimum_required has an unsupported low version"Alexandru Croitor2021-10-041-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 657525965b86cfa135bb5a814a537443163acb14. The change relied on reading the last value of the CMAKE_MINIMUM_REQUIRED_VERSION variable before one of the Qt packages is found to use it for the version check. Even if a user project has a cmake_minimum_required() right at the beginning of the project with a supported version specified, the first project() call which loads a CMake toolchain file could contain another cmake_minimum_required() call with a lower (unsupported) version and that version would be used for the check, failing the project configuration. The Android NDK ships such a toolchain file, which requires version '3.6'. Thus, relying on the last value of CMAKE_MINIMUM_REQUIRED_VERSION is not robust enough. Pick-to: 6.2 Task-number: QTBUG-95018 Task-number: QTBUG-95832 Change-Id: Iff3cb0a46e6e878569dce9c5fe915a714a034904 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Warn if cmake_minimum_required has an unsupported low versionAlexandru Croitor2021-10-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Qt6Config.cmake calls cmake_minimum_required to ensure a recent enough CMake version is used in projects. That call does not set policies in the calling subdirectory scope, because find_package introduces a new policy scope. If a project using Qt has a 'cmake_minimum_required(VERSION 3.1)' call and is configured with a recent CMake, many policies will still be set to OLD. One such policy is CMP0071 (Run AUTOMOC on GENERATED files). The policy value is queried at generation time rather than at target definition time, which means we can't influence the policy value (e.g. inside the implementation of qt_add_executable for example) The inability to influence the policy value for targets created by our own CMake functions is unfortunate and can lead to issues (in the case of the above policy to compilation / linker issues). Record the version of the last cmake_minimum_required call before the Qt packages are found and error out if the version is lower than the minimum supported one. A project can reduce the error into a warning by specifying a -DQT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT_IN_CMAKE_MIN_REQUIRED=3.xyz option when configuring the project. If the option is used and build issues arise, no official support is given. All the CMake example projects shipped with Qt specify a minimum version of 3.16 already (which is the minimum for shared Qt builds), so it shouldn't be an issue to require that in other user projects as well. Implementation wise, we follow the existing pattern to record what the minimum and computed versions for static and shared Qt builds are at qtbase configure time. These are then checked before the Qt6 or QtFoo packages are find_package'd. Amends 6518bcc167d47e1c27d082c21551b9a838b04e5d Pick-to: 6.2 Task-number: QTBUG-95018 Task-number: QTBUG-95832 Change-Id: I1a1d06d82f566c92192a699045127943604c8353 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Pass Qt6_FIND_VERSION in Qt6Config when looking for componentsAlexandru Croitor2021-08-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Fix QT_ADDITIONAL_PACKAGES_PREFIX_PATH for cross-buildsAlexandru Croitor2021-08-191-5/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Pick up *Tools components also from host QtKai Köhne2021-08-181-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Partially fix QUIETness of find_package(Qt6 COMPONENTS Foo)Alexandru Croitor2021-08-061-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Improve component / package not found error messagesAlexandru Croitor2021-08-061-12/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Enforce minimum CMake version in user projectsAlexandru Croitor2021-08-041-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Use target_link_options to propagate object librariesAlexey Edelev2021-07-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Propagate sanitizer flags to public projectsAlexandru Croitor2021-06-251-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Move dependency lookup functionality to the common macroAlexey Edelev2021-06-191-0/+1
| | | | | | | | | | 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>
* Remove target specific flags from the linker capabilities checkAlexey Edelev2021-06-161-1/+1
| | | | | | | | | | | | | Remove target specific flags from static_link_order. Move the check to the common config.tests folder. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I1368075ec6bd1e743b2b89fd93143df38a278ec2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Check the impact of static link order for user projectsAlexey Edelev2021-06-161-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Promote all targets to global within a scope when possibleAlexandru Croitor2021-06-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Add public FindPackageHelpersDominik Holland2021-06-141-0/+1
| | | | | | | | | 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>
* Implement propagation of object files to the end-point executableAlexey Edelev2021-05-271-0/+1
| | | | | | | | | | | | | | | | | | | | 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>
* CMake: Make qt_internal_walk_libs available in public projectsAlexandru Croitor2021-05-111-0/+2
| | | | | | | | | | | | | | | | | | 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>
* CMake: Refactor handling of static pluginsAlexandru Croitor2021-05-111-0/+4
| | | | | | | | | | | | | | | | | | | | 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>
* CMake: Generate better Xcode iOS projectsAlexandru Croitor2021-04-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Improve support for QT_ADDITIONAL_PACKAGES_PREFIX_PATHKai Köhne2021-03-031-1/+6
| | | | | | | | | | | | | | | | | | | 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>
* CMake: Use host variables instead of hardcoded directoriesAlexey Edelev2020-12-211-0/+10
| | | | | | | | | | | | | | | | | | | 'QT_HOST_PATH' indicates that we use crosscompilation toolchain to build project. In this case 'Qt6Config.cmake' loads 'Qt6HostInfoConfig.cmake' from host QT_HOST_PATH, that defines correct paths to host tools. Replace hardcoded paths for host tools by paths recorded in Qt6HostInfoConfig.cmake. Correct conditions for QT_HOST_PATH, evaluate it explicitly as string, but not as boolean expression. Fixes: QTBUG-86557 Pick-to: 6.0 Change-Id: Ib52bbd32478051d019a932dcb1f735e2d4aacfbf Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Enable NEW policies by CMake version with a global defaultCraig Scott2020-12-071-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Do not set PKG_CONFIG_* environment variablesJoerg Bornemann2020-11-121-10/+0
| | | | | | | | | | | | | This reverts commit 9968a211f92c2b4d5bd1fe004f16ec1c5f968dcd. The PKG_CONFIG_* environment variables should be added by the user environment, preferably by the toolchain file. Apparently, the change was added for Android before we turned off pkg-config for Android. It is not needed anymore. Change-Id: Ieeed09ae53a606c85d4937f463286b5b0f76bde9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Bump the minimum required CMake version to use Qt to 3.14Alexandru Croitor2020-11-021-2/+2
| | | | | | | | | | | | | | | | | At the moment our examples require a minimum of 3.14 due to changes in upstream CMake's Autogen functionatlity to support Qt 6. Anything lower would simply not work with Qt 6. It's not clear yet if we actually want to require 3.14, or something higher. At the very least there were many significant changes to support iOS in CMake 3.15. But for now just bump the version checked by Qt6Config.cmake to be consistent with what's in our examples. Task-number: QTBUG-88086 Change-Id: I119c2ad05a18c357fe7c659b30685af87475fc84 Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* CMake: Allow finding Qt CMake packages in additional locationsAlexandru Croitor2020-09-281-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Revert "Revert "CMake: Fix usage of find_dependency()""Joerg Bornemann2020-09-141-7/+5
| | | | | | | | ...and fix the build errors the original change caused. This reverts commit 127fb8bb5587db52216d0ac934f3111170a7cbe3. Change-Id: I4006b32734a51c5d101dd73c957f81d2a0f84ba1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Revert "CMake: Fix usage of find_dependency()"Lars Knoll2020-09-131-1/+1
| | | | | | | | | | This reverts commit 58c1c6ee5c986d502b56eb1cc57f1d9444d42031. This lead to configuration errors on some machines, blocking development. Change-Id: I744f6cc95fbaa273519ab8fc8fb492b87f5729b8 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* CMake: Fix usage of find_dependency()Joerg Bornemann2020-09-121-1/+1
| | | | | | | | | | | | The find_dependency() macro calls return() on failure, meaning any code after it will be ignored, thus checking any XXX_FOUND variables after find_dependency() is pointless. Fix the places where we use find_dependency() and set the "failed" state before the call and the "success" state afterwards. Change-Id: Ia5239c704f02a9bec972210374ffed7808b14055 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Properly handle CONFIG += thread aka Threads::ThreadsAlexandru Croitor2020-08-061-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cmake: Pick up custom Info.plist in user projectsTor Arne Vestbø2020-06-261-2/+2
| | | | | | | | 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>
* CMake: Fix pkgconfig calls when cross-compilingLeander Beernaert2020-03-261-0/+10
| | | | | | | | | | | | | | When cross-compiling with CMake, before this patch pkgconfig calls would find libraries which are part of the host system and not the target system. The current approach used is based of the discussion present in https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4478, and should be considered a temporary solution until the issue is properly addressed in upstream CMake. Change-Id: I535d4d48c2a5d34689082b80501b3b6ae30d7845 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Remove APPLE prefix from platform namesTor Arne Vestbø2020-03-161-1/+1
| | | | | | | None of the other platforms have it. Change-Id: Ib448c2c03ba03f711b507ef391977c0e6aa7c192 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Fix naming when referring to Apple macOSTor Arne Vestbø2020-03-161-1/+1
| | | | | Change-Id: Iafb5e448d0d65d42f788464fc600594a5666f9af Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Add default Info.plist for macOS with some important keysTor Arne Vestbø2020-03-131-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* Expose Patch Version in QtConfig.cmakeLeander Beernaert2019-12-111-1/+2
| | | | | Change-Id: I2166d480c0b717fc9137f8eb42d5aab7a091395d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix creation of versionless targets for toolsAlexandru Croitor2019-12-061-1/+3
| | | | | | | | | | | | | | | | | | 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>
* Always append extra cmake modules to CMAKE_MODULE_PATH in Qt6ConfigAlexandru Croitor2019-10-011-0/+6
| | | | | | | | | | | | | | | | | | | | | | 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>
* Fix examples find_package calls to work in prefix buildsAlexandru Croitor2019-09-211-1/+2
| | | | | | | | | | | | | | | | | | | 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>
* Merge remote-tracking branch 'origin/wip/qt6' into wip/cmakeAlexandru Croitor2019-06-141-1/+1
| | | | | | | | | | This changes many different CMake places to mention Qt6 instead of Qt5. Note that some old qt5 cmake config files in corelib are probably not needed anymore, but I still renamed and kept them for now. Change-Id: Ie69e81540386a5af153f76c0242e18d48211bec4
* Allow to build examples as standalone projectKevin Funk2019-06-051-3/+10
| | | | | | | | | | | | | | | | 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>
* QtConfig.cmake.in: Fix typoKevin Funk2019-06-041-1/+1
| | | | | | | | | | 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
* Encapsulate commands for building other repos into two macrosAlexandru Croitor2019-05-151-3/+0
| | | | | | | | | | | | | | | | | | | Currently to build qtsvg we have some copy-pasted code to set up the paths for QtSetup and QtPostProcess to be found. To make it cleaner, introduce two new macros called qt_build_repo_begin and qt_build_repo_end(). The first one should be called in a child repo like qtsvg, right after a find_package(Qt5) call, and the second one at the end of the repo top-level CMakeLists.txt file. In order for the macros to work, extract some of the variables which were set in Qt5Config into Qt5CoreConfig instead. This makes sure that it works also for find_package(Qt5Core) calls. Task-number: QTBUG-75580 Change-Id: I85267c6bd86f9291ec2e170fddab1006ab684b5c Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* cmake: Generate config files with Qt:: prefixKevin Funk2019-05-031-0/+2
| | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-21 00:42:17 +0000