Configuring a test as standalone would fail with the following error:
Invalid max SDK version: It should be a major version number,
without minor
This happened because _qt_internal_check_apple_sdk_and_xcode_versions
expects QT_SUPPORTED_MAX_MACOS_SDK_VERSION to be available, but it is
not yet set due to Qt6 package not being found yet.
Avoid the issue by exporting the version requirements into both
Qt6ConfigExtras.cmake and Qt6BuildInternalsConfigExtra.cmake.
Make sure to assign the variables only once.
Amends a29bff3d80219f54d0837b0e6e0577192011dea1
Amends a0bdd2195f24d8a7d880ba506afc16b41337218e
Pick-to: 6.6
Task-number: QTBUG-119490
Change-Id: Ic297eeaabf22c8c42ded1a766906f88fdb91fd3d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit cec2e42052a04cd2481c20bd4be5de2ba5ccaec2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Currently we assume that only modules that have plugins built in the
current build tree need to generate and install the
Qt<Module>Plugins.cmake file. This approach is weak since other Qt
modules might still want to provide the plugins of the certain types,
even if the module that the plugin type belongs too didn't have plugins
initially.
The fix unblocks the formally 3rd-party plugin installation and loading
chain.
Pick-to: 6.6 6.5 6.2
Fixes: QAA-2266
Change-Id: Ifc616e26a00674371c8e2fe2ca12237d153e5707
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 180afc7321c85f7f36d085b76d1be74c99da2462)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Previously we had four-ish locations where the CMAKE_BUILD_TYPE was
force set.
Twice in QtBuildInternalsExtra.cmake via
qt_internal_force_set_cmake_build_type_conditionally(), depending on
some conditions. This was executed right at
find_package(Qt6 COMPONENTS BuildInternals)
time.
And twice in qt_internal_set_default_build_type() via
qt_build_repo_begin() / qt_prepare_standalone_project() that goes
through QtSetup.cmake. This was executed only if the relevant functions
were called, rather than directly at find_package() time.
The exact logic of which build type ended up being set was very
confusing.
Refactor the code to decide the build type in one single location
when qt_build_repo_begin() / qt_prepare_standalone_project() are
called, rather than directly at find_package() time.
The actual logic when we override the build type depends on many
factors:
- when an explicit CMAKE_BUILD_TYPE is given, honor it, unless it's
a multi-config build
- when it's a multi-config build, don't set any CMAKE_BUILD_TYPE,
use the value of CMAKE_CONFIGURATION_TYPES
- when it's a qtbase build, compute a default unless an explicit value
was given
- the default is Debug if FEATURE_developer_build is ON
- otherwise the default is Release
- when it's a top-level build, only choose a build type for qtbase
- when it's another repo build, use the original build type unless
another was given explicitly (including in a top-level build)
- when it's a standalone tests build
- if qt is multi-config, the tests will be single config, due to
various CI failure reasons, this hasn't changed
- if qt is single config, use the original unless an explicit
value was given
- when it's a single standalone test build, use the original unless
an explicit value was given
To determine when an explicit CMAKE_BUILD_TYPE was given in contrast
to when it was default initialized, we now have one single function
that uses a few heuristics.
The heuristics are needed because we can't reliably determine an
explicitly given 'Debug' build on Windows, because CMake default
initializes to that.
The heuristics include:
- checking whether CMAKE_BUILD_TYPE_INIT is different from
CMAKE_BUILD_TYPE
- checking what the CMAKE_BUILD_TYPE was before the first project()
call when CMake default initializes
- we save the previous value in the qt.toolchain.cmake file
- also in QtAutoDetect during qtbase configuration
- also when building the sqldrivers project
- honoring the value of QT_NO_FORCE_SET_CMAKE_BUILD_TYPE
As a result of the above changes, the build type will be set exactly
zero or one times, for a particular build directory.
Note that the configure script also has some logic on which
CMAKE_BUILD_TYPE / CMAKE_CONFIGURATION_TYPES to pass to CMake
depending on whether -debug / -release / -debug-and-release /
-force-debug-info were passed. But once the values are passed,
CMake will honor them.
Amends 48841c34d2e86a741ec9992b9704c0fa5973503c
Amends 8c912cddebe544010e7da3f87af5b21f3328d7ec
Task-number: QTBUG-114958
Task-number: QTBUG-120436
Change-Id: I30db14d1e8e9ff9bd2d7ea1d2256cdeb9493ca0d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
(cherry picked from commit 49902cc6ce228c9365c54b0dbe777ae63720310c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
User-facing apps that are app bundles on macOS weren't linked correctly.
For example, for Qt Designer we're creating now an entry like the
following:
.../Designer.app/Contents/MacOS/Designer /usr/bin/designer6
Pick-to: 6.6
Fixes: QTBUG-120487
Change-Id: I3eada15c4c5bf31b9b08829333d3c87f76ede7a2
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
(cherry picked from commit 2921a70e5d8de5bf3f4b56b90347983aa9b1342b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Previously qt_internal_read_repo_dependencies had to be defined
before QtBuildInternalsExtra.cmake was included because the file
called the function.
Instead of calling the function in QtBuildInternalsExtra.cmake, just
call it later after the Helpers have been loaded. We can do this
because the function is always called unconditionally, so no point in
doing it in the generated file.
This lets us move the function into the QtBuildRepoHelpers.
Amends 98e8180e56322ce065e39cc1ef1d65b54caa8c25
Amends a804ac3d881fb036619f323f64e778a9e00b181d
Task-number: QTBUG-86035
Change-Id: Idffed8f2eb9d728c779b77b31eba0d24d85752ea
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This has the flaw of providing very little information and happens too many
times during the configure process.
My bad, apologies for the noise.
Change-Id: I57368f514be968e7144f364f627c110ceed20dae
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
TL;DR: This creates two changes:
1. Makes the plugin inclusion status more visible for builders for both Qt
itself and applications.
2. Allows a simple patch-point for distros to change the default
(perhaps not ideal, but good enough).
3. Does not changes the current behavior.
As discussed both in the mailing list and privately with
Alexandru Croitor and Joerg Bornemann this makes a lot os sense for Qt
on static builds and when trying to find where the plugins are so they
can be easily packaged up in order to distribute a build with all the
dependencies on it.
But at the same time it makes no sense for distributions building the
libraries in dynamic mode as it forces unnecesary build time
dependencies for for both Qt and applications like QML modules or even
PostgreSQL! [0].
[0] <https://sources.debian.org/src/martchus-qtutilities/6.10.0-1/cmake/modules/QtConfig.cmake/?hl=35#L35>
Other approaches have been considered like not shipping specific CMake
files, but this depends on the packager finding the right ones at the
right time, and does not allows end users to change the behavior if they
happen to need it.
Change-Id: Id32fbc0cf0f289edd4426fb703cf1195288aacb4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Maintain one central place - .cmake.conf - for information
about Qt's copyright.
Pick-to: 6.2 6.5
Change-Id: Ibcbce4313eba9660d459061b0ad00307e267b8f7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It might not matter as far as I understand, but having it saved as BOOL
is better if it's a boolean.
Change-Id: If35485425257ca5518f0f8a49ca5353b9ac875a8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
syncqt.pl adds an extra dependency on perl when building Qt. Modern C++
provides the convenient cross-platform way to access a filesystem and
to use regular expressions, so we may replace the perl script with C++
application. The syncqt executable is built at configure time and
installed as QtCore tool. It's running at configure time to deliver the
required header files for IDE to build a consistent code model and at
the build time to keep tracking changes in header files and generate
the missing aliases without reconfiguring. 'syncqt' only parses header
files from a CMake build tree, so the resulting Qt installation only
contains interfacing headers that belong to the platform that Qt is
built for. 'sync.profile' files are not used as the 'source of truth'
for sync qt procedure anymore, all the necessary information is taken
from either CMake files at configure time or from the module header
files while parsing them.
syncqt.pl is still in place since it's required as fallback solution
for a smooth transition to the new syncqt implementation for all qt
repositories.
This patchset only enables the C++ based syncqt for 'qtbase'
repository.
From the performance perspective C++ version works faster then perl
script, also the configure time is reduced significally on subsequent
reconfigurations - up x2 times faster when re-configuring repository,
but it also takes time to compile the tool itself the first time.
Numbers for qtbase:
syncqt.pl syncqt.cpp
initial: 0m16,035s 0m20,413s
reconfig: 0m6,819s 0m3,725s
The syncing procedure can be run separately for each module using
<ModuleName>_sync_headers targets. The 'sync_headers' target can be
used to sync all the modules at once.
Task-number: QTBUG-87480
Task-number: QTBUG-103196
Change-Id: I8c938bcaf88a8713b39bbfd66d9e7ef12b2c3523
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And also teach CMake to treat it properly instead of hardcoding the
version number.
[ChangeLog][Build System] The configure script now accepts a new
parameter -disable-deprecated-up-to which is used to remove all
deprecated code from API and ABI while building the libraries.
The version number must be specified in a hex format.
For example, it can be used like this:
/path/to/qt/configure -disable-deprecated-up-to 0x060500
to remove all code deprecated in Qt 6.5.0 or earlier releases.
Task-number: QTBUG-101510
Change-Id: I557cf83e29b867fa1052bb097985e144b5eaf34d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Variables starting with 'arg_' usually are the result of the
cmake_parse_arguments call. It's better to not use them for the regular
variables for readability.
Change-Id: I4054c63d3e48b2a27d8a632cd8908a59302afa47
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>
Removing the variable would cause nested find_dependency calls of
FooQmlPluginDependencies.cmake files to look for the Qml package
again and again.
If we got to the point of including QmlPlugins.cmake, we already know
that the Qml package was found.
Set it to TRUE after every inclusion to avoid repeated Qml package
loading.
The second inclusion pass will ensure to set the found variable to
FALSE in case if some dependency is actually missing.
Amends aad4158959890b72afdd062614c1142c100c65b5
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I562a1c2ea0abac61453a743ab2e7d2f228de7ff0
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Previously if a target depended on CorePrivate, we would write a
_qt_internal_find_qt_dependencies(... Qt6CorePrivate) call into a
FooDependencies.cmake file.
That find_qt_deps call would remove the 'Private' suffix and would run
find_dependency with NAMES set to both the altered and non-altered
names.
This would find the relevant package but it would set the wrong
_FOUND variable name, e.g it would set Qt6CorePrivate_FOUND instead
of Qt6Core_FOUND.
This in turn could cause multiple lookups of the Qt6Core package
during dependency handling because the correct _FOUND var would not be
set.
Instead of always looking for the Qt6CorePrivate package, make sure
we look for an appropriately named package for all Privates modules,
because we have the necessary info to determine the correct name.
Note that INTERNAL modules will still be looked up via a Private
suffixed package name because that's how the package name is chosen
for them.
Remove the code that accounted for Private modules in
qt_internal_remove_qt_dependency_duplicates because it's not needed
anymore.
Warn when a package name can't be queried from a target's property
because the target might not exist yet.
Add a TODO comment for the code that searches with two NAMES.
We can't remove it right now, because it might break user projects
that use stale Dependencies.cmake files.
The dbus subdirectory is added before the tools subdirectory
to ensure that the new package name extraction does not error out, due
to trying to access a target that does not yet exist.
Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Ib34ae5ed92f68b4265518c2b8802daeb1a3a04d6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Instead of trying to compute and validate the QT_HOST_PATH and
QT_HOST_PATH_CMAKE_DIR variables in the generated toolchain file,
do it in the Qt6 package.
This provides better error messages when a project is configured
without using the Qt generated toolchain file.
Because it's not done in the toolchain anymore, remove the various
host variables from __qt_toolchain_used_variables.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I1ca239ff83b8f783897e171fee352fc43e8ad7a8
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Instead of checking if QT_HOST_PATH is set during user project
configuration to find out if Qt6HostInfo should be looked up,
record if QT_HOST_PATH was provided during Qt configuration
into Qt6Dependencies.cmake and look up the package in a user
project based on that information.
This improves handling of the case where cmake is directly used
to configure a Qt project (instead of qt-cmake), which means no
QT_HOST_PATH might be set by the user, and then cmake would error out
saying that e.g. Qt6CoreTools is not found, instead of saying that
Qt6HostInfo is not found.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I0377d5440e4b5b295af73cfd4b5188f61d48e440
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We started recording extra dependencies for the QtNetwork TLS plugin,
but we never actually processed them to write out the necessary
find_package calls.
This broke static builds of qtopcua, because the OpenSSL::SSL target was
no longer created in the root scope, but only in some child ones like
src/opcua, whereas the target was referenced in generator expressions
in a different sibling scope src/declarative_opcua, leading to errors like
CMake Error at lib/cmake/Qt6/QtPrlHelpers.cmake:116
(file): Error evaluating generator expression:
$<TARGET_LINKER_FILE:OpenSSL::SSL>
No target "OpenSSL::SSL"
Call Stack (most recent call first):
lib/cmake/Qt6/QtModuleHelpers.cmake:837 (qt_generate_prl_file)
lib/cmake/Qt6/QtScopeFinalizerHelpers.cmake:21:EVAL:1
(qt_finalize_module)
src/declarative_opcua/CMakeLists.txt:DEFERRED
Make sure to process the extra deps for plugins as well.
Amends d754e43721e4f40a8dffa8b69ef883ca383a4a61
Amends 3c233175523a61e734dd5cd9bdcbb2994566f7f0
Pick-to: 6.4
Task-number: QTBUG-96283
Change-Id: I11876e0844198b3a794bc06b6691ee694fd3b1c2
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
when building Qt repositories.
When building for example qtquick3d, the Qt6QmlPlugins.cmake
file should not load the qtquick3d specific plugin config files
because the targets will be created as part of the build and cause
duplicate errors.
We already did it for static builds, but now we also do it for shared
builds.
Amends 7d6f1ee5a75cae9d122a3f0c7b3a6d03f380535e
Amends 98e8180e56322ce065e39cc1ef1d65b54caa8c25
Pick-to: 6.4
Task-number: QTBUG-94066
Change-Id: I66ca71dfa6485eded94c1ecb5eb3b23daf908b39
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Previously QtModulePlugins.cmake files were only created and
included in static library Qt builds.
Having the targets available in shared library builds would be
useful for custom project deployment purposes. One could query
the location of the plugins or use various generator expressions
referencing their location.
Ensure we always generate and include the QtModulePlugins.cmake files
regardless of the build type.
Allow opting out of including the files by setting
QT_SKIP_AUTO_PLUGIN_INCLUSION to ON, just like we allow for Qml
plugins with QT_SKIP_AUTO_QML_PLUGIN_INCLUSION.
Pick-to: 6.4
Fixes: QTBUG-94066
Change-Id: I69a5dc17762a8e43265578fc33b82b5c4b7a1f5c
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Use message(STATUS) for the 'Generating Plugins' message.
This way it will go to stdout instead of stderr, which follows the
convention we have for most of our other messages.
Also list only the modules that actually have plugins, rather than all
known modules.
Pick-to: 6.2 6.3 6.4
Change-Id: I1ea0ed71418ede54790cabd32e03e82fc69f2858
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
When recording which package version to look for in
QtFooModuleDependencies.cmake and other files like it,
instead of using PROJECT_VERSION, use the version of the
package that contains the dependency.
For example if we're hypothetically building the qtdeclarative repo
from the 6.4 branch, against an installed 6.2 qtbase, then
the Qt6QmlModuleDependencies.cmake file will have a
find_package(Qt6Core 6.2) call because qtdeclarative's
find_package(Qt6Core) call found a 6.2 Core when it was configured.
This allows switching the versioning scheme of specific Qt modules
that might not want to follow the general Qt versioning scheme.
The first candidate would be QtWebEngine which might want to
follow the Chromium versioning scheme, something like
Qt 6.94.0 where 94 is the Chromium major version.
Implementation notes.
We now record the package version of a target in a property
called _qt_package_version. We do it for qt modules, plugins,
3rd party libraries, tools and the Platform target.
When we try to look up which version to write into the
QtFooModuleDependencies.cmake file (or the equivalent Plugins and
Tools file), we try to find the version
from a few sources: the property mentioned above, then the
Qt6{target}_VERSION variable, and finally PROJECT_VERSION.
In the latter case, we issue a warning because technically that should
never have to happen, and it's a bug or an unforeseen case if it does.
A few more places also need adjustments:
- package versions to look for when configuring standalone
tests and generating standalone tests Config files
- handling of tools packages
- The main Qt6 package lookup in each Dependencies.cmake files
Note that there are some requirements and consequences in case a
module wants to use a different versioning scheme like 6.94.0.
Requirements.
- The root CMakeLists.txt file needs to call find_package with a
version different from the usual PROJECT_VERSION. Ideally it
should look for a few different Qt versions which are known to be
compatible, for example the last stable and LTS versions, or just
the lowest supported Qt version, e.g. 6.2.6 or whenever this change
would land in the 6.2 branch.
- If the repository has multiple modules, some of which need to
follow the Qt versioning scheme and some not,
project(VERSION x.y.z) calls need to be carefully placed in
subdirectory scopes with appropriate version numbers, so that
qt_internal_add_module / _tool / _plugin pick up the correct
version.
Consequences.
- The .so / .dylib names will contain the new version, e.g. .so.6.94
- Linux ELF symbols will contain the new versions
- syncqt private headers will now exist under a
include/QtFoo/6.94.0/QtFoo/private folder
- pri and prl files will also contain the new version numbers
- pkg-config .pc files contain the new version numbers
- It won't be possible to write
find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code.
One would have to write find_package(Qt6WebEngineWidgets 6.94)
otherwise CMake will try to look for Qt6Config 6.94 which won't
exist.
- Similarly, a
find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call
would always find any kind of WebEngine package that is higher than
6.4, which might be 6.94, 6.95, etc.
- In the future, if we fix Qt6Config to pass EXACT to its
subcomponent find_package calls,
a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets)
would fail to find WebEngineWidgets, because its 6.94.0 version
will not be equal to 6.5.0. Currently we don't pass through EXACT,
so it's not an issue.
Augments 5ffc744b791a114a3180a425dd26e298f7399955
Task-number: QTBUG-103500
Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Previously, this was only supported when cross-compiling, but that's an
unnecessary limitation. Instead, make it possible to build the "host"
tools (notably qmake) even when they've been found elsewhere due to
QT_FORCE_FIND_TOOLS=ON and a supplied QT_HOST_PATH.
The combination of QT_FORCE_FIND_TOOLS and QT_FORCE_BUILD_TOOLS set to
ON is useful for developers who touch content that ends up in the
bootstrap library.
QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is deprecated in favor of
QT_FORCE_BUILD_TOOLS.
[ChangeLog][CMake] QT_BUILD_TOOLS_WHEN_CROSSCOMPILING has been
deprecated in favor of QT_FORCE_BUILD_TOOLS. The latter can be used in
combination with QT_FORCE_FIND_TOOLS and QT_HOST_PATH to use tools from
a host Qt even for a non-cross build and still build the tools.
Fixes: QTBUG-99683
Change-Id: I0e5f6bec596a4a78bd3bfffd16c8fb486181f9b6
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
to QT_INTERNAL_EXAMPLES_INSTALL_PREFIX so it's clear that the
variable only affects the location of where examples
are installed.
And make sure the paths are passed as CMake paths.
Amends 1031fa15472bba3f20691cda2305e0821391c5db
Pick-to: 6.2 6.3
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: Ib92c55488b736d980da2bd88255de78e183de824
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
When configuring a static Qt with the -qt-zlib option and the build
system creates a 3rd party header module QtZlib, syncqt
does not generate a QtZlib header file that would include all its
public headers.
Then when the QtSvgDepends header is generated, it would add an
#include <QtZlib> which would break compilation of the QtSvg PCH
file (which compiles QtSvgDepends).
We have logic to exclude addition of headers from regular 3rd party
static libraries, but not header only 3rd party libraries.
Adjust the code to handle header-only 3rd party libraries, as well as
make sure it works across repos by exporting the relevant properties.
As a drive-by, also rename and export some other informational
properties.
Amends af00402d6446c0f8f085a2a482fc83c4318aa457
Amends 6fdeaea24f9035ad53ba2548a9467b3264cf01ad
Amends be2745e4788cecb0d3122081e3328e4b66923609
Pick-to: 6.2 6.3
Change-Id: I087f50b193dd845e4a5ec906e8851d63122faf80
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Introduce a new QT_INTERNAL_CUSTOM_INSTALL_DIR variable to
allow specifying an 'examples install dir' outside of the Qt prefix.
It will be used in a follow-up change to ensure we don't package
the example binaries in our CI artifacts (thus saving space).
This will be even more important when the examples will contain code
to deploy Qt libraries alongside each deployed example (which would
significantly increase the package size).
Pick-to: 6.2 6.3
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I06b4a8f9e8c57a712a356bca0f5c351a9362bc30
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
One might want to build qtbase in Release, but qtsvg or some test in
Debug mode. Before if qtbase was configured as Release, there was no
way to override that.
Now we try to detect whether a custom build type was specified to
qt-cmake / qt-configure-module / qt-cmake-standalone-test /
qt-internal-configure-tests
Note mixing won't work on Windows due to different C/C++ runtimes.
Also, now we don't force set a single build type when a multi config
generator is used as well as one opts out via the
QT_NO_FORCE_SET_CMAKE_BUILD_TYPE variable.
Pick-to: 6.2 6.3
Change-Id: I6dc4325087ff7f905ad677d87b0267e2f3e4693f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When qtbase is configured with CMAKE_STAGING_PREFIX set, then Qt modules
built against this qtbase should also get CMAKE_STAGING_PREFIX by
default. Like CMAKE_INSTALL_PREFIX in regular builds, this prefix will
be determined by the location of QtBuildInternalsExtra.cmake to support
building Qt modules against an installer-provided Qt.
CMAKE_INSTALL_PREFIX on the other hand must be exactly the value that
was provided when building qtbase.
If CMAKE_STAGING_PREFIX is specified by the user, honor it.
To opt out of automatically setting CMAKE_STAGING_PREFIX, set
QT_BUILD_INTERNALS_NO_FORCE_SET_STAGING_PREFIX to ON.
Remove the old code that was supposed to set CMAKE_STAGING_PREFIX.
Pick-to: 6.2 6.3
Fixes: QTBUG-99666
Change-Id: I20edef54c102ca9784fcdef0decf0bd83266ae11
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Each included qml Qt6FooPluginTargets.cmake file checks whether
all the dependency targets that are referenced in the file already
exist by the time the file is included.
If one of the referenced targets is missing, the file sets
${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE with a message mentioning
which targets are missing and also sets
${CMAKE_FIND_PACKAGE_NAME}_FOUND to FALSE.
All our qml package Config.cmake and Targets.cmake files are
include()d by Qt6QmlPlugins.cmake using a file(GLOB) which means the
order in which the files are loaded is implementation-defined.
Furthermore we didn't check the above set variables after each
inclusion, which means the values are overridden and the last plugin
to be loaded determines whether the Qml package is found or not.
If the last included file sets no error, it effectively silences any
previously set error.
Ever since we added dependencies between the qml plugin targets
themselves, we hit the above situation and depending on the platform,
no error was shown because the last file overrode any errors.
But we finally got a specific platform (wasm) which unearthed the
problem (QTBUG-97478). This can happen for any static Qt build though.
To fix this properly, we will most likely have to rewrite the whole
inclusion mechanism to use find_package() so that dependencies
can be resolved recursively as needed. This is a non-trivial change
that will have to be addressed in both qtbase and qtdeclarative.
In the mean time, a stop-gap solution that this change implements is
to include all the files while ignoring any error messages.
Then include the files one more time and check for error message after
each included file.
All qml plugin targets should have been brought into scope with the
first round of inclusions, thus circumventing "missing referenced
target" errors, while still catching any other possible errors.
Amends
6fd1216801f078f65be2cbc748cc459cb6912a4f
9fc302e6d146878103b3d105dce49c7695fcf93a
c368175a9e0a0c120b5bb8a0a02859bfc0cf42ba
in qtdeclarative.
Pick-to: 6.2 6.2.1
Fixes: QTBUG-97478
Task-number: QTBUG-95609
Task-number: QTBUG-97099
Change-Id: I157fa93fc979d726cd221d969b995b3642aeec77
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Conan CI builds can built a qt repository in a repo-target-set
configuration. An example of that is qtscxml.
When building standalone tests, qt_build_tests includes a repo
specific TestsConfig.cmake file to call find_package on the modules
that were built as part of that repo.
That doesn't quite work with a repo-target-set build which is enabled
when the repo is built with a QT_BUILD_SINGLE_REPO_TARGET_SET value.
The TestsConfig.cmake file would be overridden with different contents
on each configuration.
Fix that by including the QT_BUILD_SINGLE_REPO_TARGET_SET value as
part of the TestsConfig.cmake file to be generated and included.
This means that when configuring the standalone tests, the same
QT_BUILD_SINGLE_REPO_TARGET_SET value should be passed, so that the
correct packages are found.
Add some debug statements to allow checking which TestsConfig.cmake
file is loaded when the standalone tests are configured with
--log-level=DEBUG.
Adjusts to 4b09522c23e9efdf83ba8d4af436d8a700ccb66e
Amends de3a806def4b9a754825a2233c9d4952a9b2d0eb
Amends e7f188b2d2f10941006be7b0e7197b3c1ebdefdb
Pick-to: 6.2
Task-number: QTBUG-96253
Change-Id: I7c22aaad88fe8e6fce23046543363316203f6e8d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Module may have specific module include name that should be taken into
account when specifying module include directories in different places.
The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to
the common naming rules and the property is used to preform include
paths instead of the direct use of the module name.
Add additional paths generated by qt_internal_module_info to keep them
consistent across all cmake files.
Pick-to: 6.2
Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
_<module>_MODULE_DEPENDENCIES variable in the
<module>Dependnecies.cmake should only contain the list of targets that
module depends on, but not versions. Version of the first module
appears in the list because of the regression introduced in
425ff34aa10a02524f2d52f544dc00b539ef9a26
Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26
Pick-to: 6.2
Change-Id: Iaa42120af6bac742bdf0f8d389bd8e5bdef9c1d1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The value of QT_UIKIT_SDK is used in configure tests via
qt_config_compile_test -> qt_get_platform_try_compile_vars.
Up till now QT_UIKIT_SDK was only available in qtbase only.
Save the value in BuildInternals to ensure it's used for other repos
as well.
Change-Id: I46f372267782f1c8e7d48c237fe0264ac72d33bb
Pick-to: 6.2
Task-number: QTBUG-95838
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
After introducing the _qt_module_has_headers target property, it's
better to replace the INTERFACE_MODULE_HAS_HEADERS use by
_qt_module_has_headers since properties duplicate each other.
Pick-to: 6.2
Change-Id: I4d62ed71b8ed8263f51d8575628693122580b4a7
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
If Vulkan headers are present on the system when qtbase is configured,
QtGui and QtOpenGL should be compiled with Vulkan support.
If a user project uses a Qt built with Vulkan support, but their system
is missing Vulkan headers, the project configuration needs to succeed.
The project will get compilation errors if it uses Vulkan headers, but
that's intended.
This use case was broken when fixing Vulkan to be found when building
Qt for Android.
Fix the regression with a combination of things
1) Mark the WrapVulkanHeaders package as optional (already the case)
2) Use the include directories directly when compiling Gui and OpenGL
3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to
consumers only if the target exists. It won't exist if Vulkan
include dirs are not found
This also requires some changes in pri and prl file generation.
For prl file generation, we don't want to link to the
WrapVulkanHeaders target, so we filter out all dependencies that
use TARGET_NAME_IF_EXISTS for anything that calls
__qt_internal_walk_libs which includes qt_collect_libs.
For pri files, we make sure to generate a uses=vulkan/nolink clause
by inspecting a new _qt_is_nolink_target property on the target.
We also don't add include dirs to the pri file if the new
_qt_skip_include_dir_for_pri property is set.
This is intended for Vulkan, because there is separate qmake logic to
try and find the include dirs when configuring a user project.
As a drive-by, fix nolink handling for WrapOpenSSLHeaders.
Amends bb25536a3db657b41ae31e1690d230ef8722b57d
Amends 7b9904849fe1a43f0db8216076a9e974ebca5c78
Pick-to: 6.2
Fixes: QTBUG-95391
Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
The optional components arguments were not handled before which
caused the recorded package information for static builds to be
incorrect, it only recorded the package name without the component.
Remove REQUIRED_COMPONENTS TODO, there is no such find_package option,
it's already handled by the regular COMPONENTS code path.
Amends 07b6d3367debd8f15974abf0f5cdf48f0fe3a536
Pick-to: 6.1 6.2
Fixes: QTBUG-94501
Change-Id: Ib48a7befcb70e20c3f21315897d51d3064b48134
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Dominik Holland <dominik.holland@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When building Linux packages, we pass OpenGL_GL_PREFERENCE=LEGACY when
building qtbase. This is done to link against legacy OpenGL libs.
When building non-qtbase repos, we also need to set this variable to the
same value we have in qtbase.
Pick-to: 6.1
Task-number: QTBUG-89754
Fixes: QTBUG-94040
Change-Id: I567b629d245025d2b1544b91cfc265a9c921725f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In cmake, targets are used as an entity for modules. This causes a
number of problems when we want to manipulate a module as a separate
entity with properties associated with it.
The _qt_internal_module_interface_name target property is introduced to
represent the module entity. All modules write a name to this property,
which will subsequently expand into the module name matched with
the module name in qmake.
The 'qt_internal_module_info' function is responsible for providing the
correct values for the module properties used when working with a module
target.
Unlike qmake, for internal modules in cmake it is expected that the
Private suffix will be specified explicitly. In case the user wants to
have a different module name, an additional argument
MODULE_INTERFACE_NAME of the qt_internal_add_module function is
introduced.
This also changes the way how target dependencies are collected and
resolved. Since the 'Private' suffix no longer means an unique
identifier of the module 'Private' part, we look for the both Private
and non-Private package names when resolving dependencies.
TODO: This change doesn't affect the existing internal modules, so to
keep compatibility with the existing code the existing internal modules
create 'Private' aliases. The code that provides backward compatibility
must be removed once all internal modules will get the proper names.
Taks-number: QTBUG-87775
Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
... and configuring another repo using qt-configure-module.
It's possible to configure a top-level Qt with a subset of repos and
then afterwards configure additional repos with qt-configure-module.
We didn't define QT_REPO_DEPENDENCIES in that case, which caused all
plugin config files to be loaded on reconfiguration, thus causing
duplicate target errors.
Move the QT_SUPERBUILD check to be done every time in
QtBuildInternals.cmake rather than when configuring qtbase/qt5.
Amends 98e8180e56322ce065e39cc1ef1d65b54caa8c25
Pick-to: 6.1
Fixes: QTBUG-86670
Fixes: QTBUG-91887
Fixes: QTBUG-92578
Change-Id: I975835ffa02f702799a3c9f68a5e059d2763a951
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Previously, in a top-level build we always generated the final prl
file somewhere under QT_BUILD_DIR (which is qtbase_build_dir). After
each repo was processed by QtPostProcess.cmake, we installed the prl
files found in PROJECT_BINARY_DIR.
For qtquickcontrols2 this meant that qml plugin prl files were placed
under qtbase/qml, but we tried installing the prl files from
qtquickcontrols2/qml, which didn't have any prl files.
In a static Qt build, qmake's qt.prf calls qmlimportscanner to
identify which plugins should be linked to the executable. This worked
fine because the plugin .pri files were installed correctly.
None of the qml plugin library dependencies were linked in though.
This is supposed to happen in qmake's C++ code where it tries to
find the associated prl file of a linked library in order to extract
all its dependencies. Because no prl file was found, linking failed
with multiple undefined symbols.
Fix this by installing the prl files from QT_BUILD_DIR rather than
PROJECT_BINARY_DIR.
Note that this will create multiple install rules for certain files,
but it's harmless. An example is imageformats.
We process qtbase plugins, see qjpeg, issue an install rule from under
the qtbase/plugins/imageformats folder. We then process
qtimageformats plugins, see webp, issue another install rule from
under qtbase/plugins/imageformats.
The first install rule will install both qjpeg and qwebp, the second
install rule will merely say all plugins are up-to-date.
Pick-to: 6.1 6.0
Change-Id: I8a4bb67bfafc1d016eab62f4fe66b6ba378ceeb2
Fixes: QTBUG-93021
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Use the same approach we use for iOS, which is to set multiple
CMAKE_OSX_ARCHITECTURES values and let the clang front end
deal with lipo-ing the final libraries.
For now, Qt can be configured to build universal macOS libraries by
passing 2 architectures to CMake, either via:
-DCMAKE_OSX_ARCHITECTURES="x86_64;arm64"
or
-DCMAKE_OSX_ARCHITECTURES="arm64;x86_64"
Currently we recommend specifying the intel x86_64 arch as the first
one, to get an intel slice configuration that is comparable to a
non-universal intel build.
Specifying the arm64 slice first could pessimize optimizations and
reduce the feature set for the intel slice due to the limitation
that we run configure tests only once.
The first specified architecture is the one used to do all the
configure tests.
It 'mostly' defines the common feature set of both architecture
slices, with the excepion of some special handling for sse2 and
neon instructions.
In the future we might want to run at least the Qt architecture config
test for all specified architectures, so that we can extract all the
supported sub-arches and instruction sets in a reliable way.
For now, we use the same sse2 hack as for iOS simulator_and_device
builds, otherwise QtGui fails to link due to missing
qt_memfill32_sse2 and other symbols.
The hack is somewhat augmented to ensure that reconfiguration
still succeeds (same issue happened with iOS). Previously the sse2
feature condition was broken due to force setting the feature
to be ON. Now the condition also checks for a special
QT_FORCE_FEATURE_sse2 variable which we set internally.
Note that we shouldn't build for arm64e, because the binaries
get killed when running on AS with the following message:
kernel: exec_mach_imgact: not running binary built against
preview arm64e ABI.
Aslo, by default, we disable the arm64 slice for qt sql plugins,
mostly because the CI provisioned sql libraries that we depend on only
contain x86_64 slices, and trying to build the sql plugins for both
slices will fail with linker errors.
This behavior can be disabled for all targets marked by
qt_internal_force_macos_intel_arch, by setting the
QT_FORCE_MACOS_ALL_ARCHES CMake option to ON.
To disble it per-target one can set
QT_FORCE_MACOS_ALL_ARCHES_${target} to ON.
Task-number: QTBUG-85447
Change-Id: Iccb5dfcc1a21a8a8292bd3817df0ea46c3445f75
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
When building and installing a Qt repo that provides plugins for a Qt
module within a different repository (for example, qtimageformats
providing imageformat plugins for QtGui), re-configuring that repository
would result in configuration errors like
"add_library cannot create ALIAS target "Qt6::QTgaPlugin" because
another target with the same name already exists."
This happened, because the find_package(Qt6 COMPONENTS Gui) calls pulled
in the Qt6*PluginConfig.cmake files that create imported targets for the
plugins we want to build.
To fix this, when building Qt, we now load only plugins that are
provided by repositories the currently building repository depends on.
We read the repo dependencies from dependencies.yaml when the
Qt6BuildInternals package is loaded, but only in static builds and only
if we're currently building a Qt repository.
To find out whether we're building a Qt repository, we check whether
QT_REPO_MODULE_VERSION is defined. We cannot check QT_BUILDING_QT,
because that variable is not available for the first find_package calls
in the repository's top-level project file.
In each Qt6*PluginConfig.cmake file, we bail out if the plugin's
repository is not one of the ones in QT_REPO_DEPENDENCIES.
Fixes: QTBUG-86670
Fixes: QTBUG-91887
Change-Id: I8f6c8398032227032742f1ca019e983ff2bcd745
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
androiddeployqt relies on *-android-dependencies.xml files to know
what dependencies like jar files and permissions a Qt module requires.
CMake create those files under Qt prefix's lib dir but CMake was not
accounting for module plugins.
Fixes: QTBUG-90812
Pick-to: 6.1 6.0
Change-Id: Ib3b2e2bb237159b4851ac0f23dc75f8e56af3f7a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
