qt5base-lts/.cmake.conf

set(QT_REPO_MODULE_VERSION "6.2.0")
set(QT_REPO_MODULE_PRERELEASE_VERSION_SEGMENT "alpha1")

# Minimum requirement for building Qt
set(QT_MIN_SUPPORTED_CMAKE_VERSION "3.16")

# Policy settings for commands defined by qtbase. These will also be injected
# into the top level policy scope of each Qt module when building Qt so that
# modules have the same policy settings as qtbase by default. They can be
# overridden by individual Qt modules in their own .cmake.conf files if needed.
#
# NOTE: These two values are also hard-coded in QtBuildInternalsConfig.cmake
#       because that file is used in-place by a superbuild, so there is no
#       opportunity for substituting the values from here. Keep both locations
#       in sync.
set(QT_MIN_NEW_POLICY_CMAKE_VERSION "3.14")
set(QT_MAX_NEW_POLICY_CMAKE_VERSION "3.19")
Bump version Change-Id: Id34c912da6076994fab38514f66036eb7b787cff 2021-02-18 05:20:21 +00:00			`set(QT_REPO_MODULE_VERSION "6.2.0")`
Conan: Read status flag from .cmake.conf The status information (alpha1, beta2, rc3, ...) needs to be part of the Conan package reference. As Conan supports semantic versioning the best place to put the status is to append it to the version string: qtbase/6.2.0-alpha1@qt/everywhere qtbase/6.2.0-beta2@qt/everywhere qtbase/6.2.0-rc3@qt/everywhere qtbase/6.2.0@qt/everywhere Other Conan packages declaring a dependency can use e.g. syntax: # notice the asterix character after version self.requires(f"qtbase/[<=<version>, include_prerelease=True}]@..) This way the status information is not in the Conan channel part and downstream consumers of the Conan package does not need to update the dependency (Conan reference string) every time the version changes. Put the status information next to Qt version string in .cmake.cache. Task-number: QTBUG-94385 Pick-to: 6.2 Change-Id: Ib277f99ea1e87253b93f59e463bd6c7dd8b3203e Reviewed-by: Toni Saario <toni.saario@qt.io> 2021-05-27 08:24:35 +00:00			`set(QT_REPO_MODULE_PRERELEASE_VERSION_SEGMENT "alpha1")`
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
			`# Minimum requirement for building Qt`
Lower the CMake minimum required version for single-config builds Ubuntu 20.04 is a supported platform and comes with CMake 3.16. The current state of the Qt build works fine with this CMake version, mainly because the default build on Linux is single-config. For multi-config builds we have higher version requirements as documented in cmake/README.md. This lowers the barrier for users using single-config builds who don't want or cannot upgrade to CMake >= 3.18. For Ninja Multi-Config builds, which were introduced by CMake 3.17, we yield a warning that 3.18.3 is the lowest supported version. Pick-to: 6.0 Change-Id: Ia918b9f2b494508e86301ffc0e138d3ad4dbaf86 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io> 2021-01-08 13:31:26 +00:00			`set(QT_MIN_SUPPORTED_CMAKE_VERSION "3.16")`
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
			`# Policy settings for commands defined by qtbase. These will also be injected`
			`# into the top level policy scope of each Qt module when building Qt so that`
			`# modules have the same policy settings as qtbase by default. They can be`
			`# overridden by individual Qt modules in their own .cmake.conf files if needed.`
			`#`
			`# NOTE: These two values are also hard-coded in QtBuildInternalsConfig.cmake`
			`# because that file is used in-place by a superbuild, so there is no`
			`# opportunity for substituting the values from here. Keep both locations`
			`# in sync.`
			`set(QT_MIN_NEW_POLICY_CMAKE_VERSION "3.14")`
			`set(QT_MAX_NEW_POLICY_CMAKE_VERSION "3.19")`