We set the CMP0156 policy to NEW for Apple platforms for each created
Qt target, but the debug message is generic, so we should only show it
once.
Amends c20d7bcb86361d0c9f8af3807dcad9db1a3a5ca0
Pick-to: 6.8
Task-number: QTBUG-135978
Change-Id: I332bd357999647df1d5f715d154fb568911889b1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 674a6dc5f66fce1cbe77a593e1fc942290d3f9b1)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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.8 6.5
Fixes: QTBUG-135978
Change-Id: I4d6e6c2a01e7092b417fc669d2aea40cf2dca578
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit c20d7bcb86361d0c9f8af3807dcad9db1a3a5ca0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We updated the minimum CMake version used in CI for Qt 6.9+ to 3.22.
Enforce the minimum CMake version in CI to avoid regressions.
This reverts commit 5803af38aab09b7e47230a494e14654031d024e7.
Task-number: QTBUG-131169
Change-Id: Ifc91644dd26e465be44bfa7cfe6f99e295a174a9
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit dcd057a31b54de637a5ca8bb8a5d46e753d3066a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
So we can raise the minimum CMake version, without having to wait for
that CMake version to be provisioned in qt5.git.
This change will be reverted later, once the provisioning is done.
Task-number: QTBUG-131169
Change-Id: I1ebdc40abcc4a72617bb7742e8dca9bcc16fee94
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Currently we have two options that allow overriding the minimum CMake
version required to either build or use Qt:
- QT_FORCE_MIN_CMAKE_VERSION_FOR_BUILDING_QT
- QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT
These options require specifying an exact CMake version that should be
allowed, which is a bit cumbersome.
Introduce two new options that allow using any CMake version without
specifying the exact version.
- QT_FORCE_ANY_CMAKE_VERSION_FOR_BUILDING_QT
- QT_FORCE_ANY_CMAKE_VERSION_FOR_USING_QT
Also introduce a Qt CI specific check that would allow using any CMake
in Qt's CI Coin, to allow decoupling of the minimum CMake version bump
from the provisioning of the new minimum CMake version.
This check should only be enabled temporarily, and then reverted back
once the provisioning is done.
The current change has the check disabled, it will be enabled in a
follow up change, so it's easier to revert.
As usual, using any of these options is not officially supported.
Pick-to: 6.8
Task-number: QTBUG-131169
Change-Id: Icc3f51ad457ebf8f4251309be97e72a3ff4cd2e0
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We want to avoid using the NEW behavior of CMP0156, since the linking
order we specify matters in several cases, even if this lead to
library duplication in linker command line. Until the NEW policy
behavior with the Qt code is not fully tested we should force the
policy to OLD, and keep the existing behavior.
Pick-to: 6.8 6.7 6.5
Change-Id: I61641f499e71a14d90b4d92419a6b916029dbc0b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
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>
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>
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>
