To not disturb the qmake build we kept syncqt.pl in <src>/bin but
installed it to libexec. This is not necessary anymore.
This also removes the need for having syncqt.pl in both, bin and libexec
in the build dir of qtbase.
Pick-to: 6.1
Fixes: QTBUG-91076
Change-Id: I44b014ea41e3f00c420e02fd5c76f11169340b8c
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
QtAutoDetect.cmake did read the (possibly detected) toolchain file and
looked for the string "The Android Open Source Project" to deduce that
we want to build for Android. This has been done, because we're
autodetecting the platform before the first project comment, i.e. before
the toolchain file is loaded.
This magic string detection is a bit fragile, and we need a similar
approach for WebAssembly. A more robust approach would be to fetch the
value of CMAKE_SYSTEM_NAME from the toolchain file without actually
loading it.
Now, we run a CMake script that includes the toolchain file and prints
variables were interested in. The calling code reads these variables and
stores them in prefixed variables in the current scope.
Change-Id: Ide9ea3054e1453d17129523e1ec86ecaed55af2a
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
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>
When packaging different Qt versions for Linux distributions (or any
distribution with a common bin dir), Qt tools cannot be installed to
/usr/bin, because the executable names of the different Qt versions
clash.
To solve this conflict, our recommendation is to install Qt's tools to
/usr/lib/qt6/bin and to create versioned symlinks to user-facing tools
in /usr/bin.
User-facing tools are tools that are supposed to be started manually by
the user. They are marked in Qt's build system. Distro package
maintainers can now configure with
-DCMAKE_INSTALL_PREFIX=/usr
-DINSTALL_BINDIR=/usr/lib/qt6/bin
-DINSTALL_PUBLICBINDIR=/usr/bin
and will find a file called user_facing_tool_links.txt in the build
directory after the cmake run. Nothing will be installed to
INSTALL_PUBLICBINDIR.
Each line of user_facing_tool_links.txt consists of the installation
path of a user-facing application followed by a space and the versioned
link name in INSTALL_PUBLICBINDIR.
Example content:
/usr/lib/qt6/bin/qmake /usr/bin/qmake6
To actually create the versioned symlinks, the content of this file can
be fed to ln like this:
xargs ln -s < build-dir/user_facing_tool_links.txt
Or the package maintainer may decide to do something completely
different as suits their needs.
This patch adds the USER_FACING argument to qt_internal_add_tool to mark
tools as user-facing. In addition, every Qt created by
qt_internal_add_app is treated as user-facing.
The only tool this patch marks as user-facing in qtbase is qmake.
Pick-to: 6.1
Fixes: QTBUG-89170
Change-Id: I52673b1c8d40f40f56a74203065553115e2c4de5
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Contrary to its name, this command was also setting a target property.
Since it was only called in one place and that caller can just as
easily set the property instead, rename the command to make clear its
internal nature and refactor it so that the caller is responsible for
setting that property instead.
Also make it an error rather than just a warning if the command is used
for a target that doesn't belong to any module. Since this is now
unambiguously an internal command, we should always expect the target
to belong to a module.
Pick-to: 6.1
Change-Id: I929a652ddd482653868fc9df887f38f4bc7f35d9
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Since the QT_CONFIGURE_HOSTBINDIR_TO_HOSTPREFIX_PATH and
QT_CONFIGURE_HOSTBINDIR_TO_EXTPREFIX_PATH definitions keep the same
value in modern CMake build, no need to have special handling in cases
where these values are used in qmake. Also it will be useful to
specify the relative path to the prefix directory from the directories
different of 'bin' when use QMakeLibraryInfo.
Task-number: QTBUG-75870
Change-Id: I5a777001eb334dcf05e22853a514d4257352d59b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Move the qmake-specific logic of the QLibraryInfo class to
qmake internals. 'qconfig.cpp.in' now stores information about
the library info entries to keep them consistent between qmake
and the Core library. qmake requires specific features enabled
in the Core library, so building qmake will be skipped if the
features are not enabled.
All flags directly related to the qmake have been removed from
Core lib.
Remove all bootstrap related sections from qmake CMakeLists.txt
Task-number: QTBUG-89369
Change-Id: I26de157d3bfd4a5526699296e9d46e1c180b89ae
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
The code branch for the INTERNAL argument did nothing, and we never call
qt_internal_add_linker_version_script with INTERNAL.
Change-Id: Ie369b4dac29cd1a977433ebfd662c198a3e1d0f2
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Putting each keyword on its own line makes it much easier to read and
improves maintainability. It is friendlier to source control when
keywords need to be added or removed.
This commit introduces no functional change.
Pick-to: 6.1
Change-Id: I79efd039e5afa5f11f1d859405d6487ad6b3beb2
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In static per-repo builds, we have a mix of targets provided by
packages and targets provided by the main build. For the builds that
create the packages, we must avoid adding a dependency for the main
module library target on its associated plugin targets or else the
package config files end up with a cyclic dependency that cannot be
resolved when something tries to consume them. This only happens for
static builds because we have been attaching a linking relationship
to the main module library that isn't really a true dependency, we
attached it only for convenience of things linking to that module
library.
To preserve that convenience linking without breaking the config
packages, we use the QT_NO_CREATE_TARGETS condition to prevent CMake
seeing that relationship when generating the *Config.cmake files.
Creating these relationships will be delayed until the plugin's
*Config.cmake file is loaded, at which point it will add itself to
the main module library's imported target INTERFACE (this was already
done before, we just now rely solely on that).
Task-number: QTBUG-90819
Pick-to: 6.1
Change-Id: Id725742182bcda64841be84fe1650bafb9151bb1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The pro2cmake.py conversion script faithfully reproduced the .pro files
for the plugins, which specified the libraries as public. But in CMake,
the implications of this are that public usage requirements should then
be propagated to consumers. We don't expect any consumers, since a
plugin is created as a MODULE library in CMake, so for Windows we don't
even have an import library to link with. The only exception to this is
for static builds where plugins are created as STATIC libraries
instead, but only in certain controlled situations do we then link to
plugins. Even then, usage requirements are not expected to propagate to
the consumers, so these relationships should always be specified as
private.
This change warns on any PUBLIC usage requirements specified for a
plugin. This check is disabled by default to avoid spamming CI builds
for repos that haven't been fixed yet. The check can be enabled by a
CMake cache option, which is intended for developers to use locally
when fixing this issue in other repos (all plugins in qtbase should
not trigger this warning as a result of changes in this commit).
Task-number: QTBUG-90819
Pick-to: 6.1
Change-Id: I09f2c8da77db1193ad3370f85d367dfc6ab7b9a6
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
[ChangeLog][Build System] Tools that are called by the build system and
are unlikely to be called by the user are now installed to the libexec
directory.
This is a step towards easier co-installability of different Qt
versions.
Pick-to: 6.1
Task-number: QTBUG-88791
Change-Id: Id19575b5ba27795f7715e4ea6a09391b26dd4942
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
We had two workarounds:
* script that adds Gui to tests
* create a symbolic link for the qt install dir to fake_prefix which
androiddelployqt was expecting them to be under
Both issues are fixed, thus removing the workarounds.
Pick-to: 6.1 6.0
Change-Id: Ic022bece15afe92c693d573893d260b13b4227ed
Reviewed-by: Heikki Halmet <heikki.halmet@qt.io>
QMake used to allow retrieving the Android features list for a modules.
The dependencies are written to *-android-dependencies.xml files and are
read by androiddeployqt. This option was missed at some point along the
way of writing CMake port for Qt 6.
Pick-to: 6.1 6.0
Change-Id: Ic0b82f024567e640968f97aeff2db1888f2b53a5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This will be used to access host tools that are installed in
${prefix}/libexec instead of ${prefix}/bin.
Pick-to: 6.1
Change-Id: I36c4b5736330f8229d267a117c65d55cd5e12758
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Initial replacement of boolean INPUT_ variables to the FEATURE_
variables was wrongly changed to updating of the INPUT_ variable
value to ON/OFF value. This causes potential issues when INPUT_
variable has explicit check for 'yes' or 'no'.
The feature evaluation step enables FEATURE_ variables in case if
the corresponding INPUT_ variable contains a positive CMake value.
So there is no need to process boolean INPUTs at the argument
processing step.
Also no need to keep the special opengl case, since it will be
processed correctly.
Fixes: QTBUG-91158
Pick-to: 6.0
Pick-to: 6.1
Change-Id: I96bb7903a904ae3cf788d7ef7d4e0c019046eb95
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add the INSTALL_DIR argument to qt_internal_add_tool to allow
installation of tools in other locations than INSTALL_BINDIR.
Pick-to: 6.1
Task-number: QTBUG-88791
Change-Id: I88ede81a4c13c82f6d209156d3801ce130f8fc10
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
The headers are already somewhat tested with C++17 in the regular
build. So let's try in the headers_clean check with C++20 instead.
Using C++20 with MSVC 19.28 doesn't work yet though:
corelib/tools/qalgorithms.h(247): error C2039: 'popcount': is not a member of 'std'
corelib/tools/qhashfunctions.h(311): note: see declaration of 'std'
corelib/tools/qalgorithms.h(247): error C3861: 'popcount': identifier not found
...
Task-number: QTQAINFRA-4242
Change-Id: I1b48bcb9656fe1587fe03d3a17e3484c693aa295
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Tests should follow their default output of txt as when run directly,
and any output configuration should be handled by the CI system.
Change-Id: Id0d72318df5edad1c58ac637e827d6043884e829
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Toni Saario <toni.saario@qt.io>
comply with the api version used by default with androiddeployqt and
in docs. Google play also requires api 29 as minimum.
Task-number: QTBUG-90943
Pick-to: 6.1 6.0
Change-Id: I05e2a90b4d7f2120b0198e3fb7b8b1b2398eba93
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Normal Android apps require Qt::Gui dependency and since tests don't
need to handle any special cases for an app without Qt::Gui, let's add
it by default.
This also will allow us to remove some workarounds done on CI side to
run tests for Android.
Fixes: QTBUG-90870
Pick-to: 6.0 6.1
Change-Id: I845650c17a1b73e4c4977043f863ec44e50f06c3
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
We must not guess the compiler from the -platform argument if one of the
following holds:
- the CXX/CC environment variables are set
- the CMAKE_CXX_COMPILER/CMAKE_C_COMPILER variables are passed
Pick-to: 6.1
Fixes: QTBUG-90914
Change-Id: Iff7a0e7b8857f77333f1705f118d7952af5234ba
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The attempt to call target_link_libraries on OpenSSL::Crypto failed when
this target was added as UNKNOWN library by FindOpenSSL.cmake.
Instead, set the INTERFACE_LINK_LIBRARIES property directly.
Pick-to: 6.1 6.0
Fixes: QTBUG-90925
Change-Id: Idbc1379c89480225fc7a8d417416ed20404a1122
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
When a feature is set in qtbase and is later set to another value,
an error occurs and an error message is given. This patch
changes the error message to contain both the preexisting and the
new value
Change-Id: Ifa9fc1f06bfde40e8fd5dfdf30165d4393abbd28
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This prevented androiddeployqt from properly deploying libraries which
specify init class via the ":" delimiter.
Pick-to: 6.0 6.1
Change-Id: Ib9cfa7edc864d7d540577df22284ceb9714a2511
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Keep the c++2a feature, but make it an alias for compatibility
purposes.
Pick-to: 6.1
Change-Id: I6f153109be84659806f1b7a57a88a187875166d8
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This is supposed to be mapped to INSTALL_TRANSLATIONSDIR, not
INSTALL_TRANSLATIONDIR (without the s).
Pick-to: 6.0 6.1
Fixes: QTBUG-90946
Change-Id: Icec93ffc0dc80d9ac7cf6cf1b13824bc2a1e795f
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
The unquoted 'string(FIND ${toolchain_file_content} ...)' call fails for
multiline content of the variable toolchain_file_content, so add
quotes around, fixes:
[...]
CMake Error at cmake/QtAutoDetect.cmake:42 (string):
string sub-command FIND requires 3 or 4 parameters.
Call Stack (most recent call first):
cmake/QtAutoDetect.cmake:311 (qt_auto_detect_android)
CMakeLists.txt:19 (include)
[...]
-- Configuring incomplete, errors occurred!
in case the given toolchain file starts with multiple lines
in the first 80 characters, e.g. in the case of buildroot:
#
# Automatically generated file; DO NOT EDIT.
# CMake toolchain file for Buildroot
#
[...]
Task-number: QTBUG-90980
Pick-to: 6.0 6.1
Change-Id: I8e038e08d83016e8253f2e83b2efb8f06034c6cd
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Developer builds with RelWithDebInfo should also make benchmarks, it
is how we get good traces.
Change-Id: I009d40580d5d784f78bd18ebf21887ce3c1fa97d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In apple systems it's necessary to pass the framework paths to the moc
generator to resolve required header files. We need to collect framework
paths for all INCLUDE_DIRECTORY_TARGETS and add them to the command line
of the moc generator.
Task-number: QTBUG-84906
Change-Id: I9e6356e7e0a5f2493823ec764a48b0b8f1c8c10d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When using static OpenSSL, HAVE_openssl test will fail, because of
unresolved external symbols. These symbols are from Ws2_32.lib and
Crypt32.lib, which CMake does not link by default. In qmake build
system, we can use OPENSSL_LIBS variable to specify these system
libraries. But there is no similar variable in CMake build system.
Accordingly, we should let OpenSSL::Crypto target link these libraries.
Upstream issue:
https://gitlab.kitware.com/cmake/cmake/-/issues/19263
Pick-to: 6.0
Change-Id: I5f27790b251d0a0f71aaf2aed2b933aeb3326f1f
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add internal function to cleanup compiler flags out of the
CMAKE_xxx_FLAGS_xxx variables. Use introduced interface to clear
the '/EHsc' flag for the MSVC compiler family. This adjusts the
CMake behavior to the qmake one.
Change the 'EXCEPTIONS' option handling in helper functions. Add
ability to add enabling and disabling exception flags. Previously
it was only possible to add disabling exception flags.
Fixes: QTBUG-89952
Change-Id: I60d47660a97ae9b5a1d1f4107d352c9e97890144
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Header files of a Qt module are usually found in subdirectories.
Avoid creating object file paths like "header_foo/bar.h.o".
When building with conan, the "header_foo" subdirectory was not created
for whatever reason.
Now, we make sure we have clean object file paths, e.g.
"header_check/foo/bar.h.o", and we create the directory upfront before
invoking the compiler.
Fixes: QTBUG-90529
Change-Id: Ifa5d6b97e07fc4e249c58cda5128439d60b14f5f
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
(cherry picked from commit 54980200c79b466a276a4d3054390e4b3162e9ed)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Commit 18fc9e1bf8 introduced a
Windows-only QT_TOOL_PATH_SETUP_COMMAND to make it possible to
call the tool of a module while building the module itself.
The "set PATH=..." command in QT_TOOL_PATH_SETUP_COMMAND was flawed,
because it contained escaped double quotes which made the set command ineffective.
Fix this by removing the escaping of the double quotes.
This was uncovered when porting qtscxml to CMake.
Change-Id: I5909aa841e7895d6d0feb4037a935b805ccfdc99
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In QtSetup.cmake the PROJECT_VERSION_MAJOR variable was used to
identify prefix of 'Qt<version>HostInfoConfig.cmake'.
Qt<version>HostInfo is not found, if project version differs
from qtbase version.
Move the 'INSTALL_CMAKE_NAMESPACE' and 'QT_CMAKE_EXPORT_NAMESPACE'
variables to 'QtBuildInternalsConfig.cmake'. In this case
variables will be exposed for a wider list of internal routines.
Use the 'INSTALL_CMAKE_NAMESPACE' variable as prefix to find
Qt<version>HostInfo module.
Fixes: QTBUG-90345
Change-Id: Ic595d1c5beb74f34e69b58e18590a3afc2f346f7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add CMake upstream(3.20.0) version of FindPostgreSQL.cmake, to avoid
server-related headers lookup.
Avoid using the Qt version of the PostgreSQL module, if it's
older than the CMake's one.
Fixes: QTBUG-89639
Change-Id: I71a0c3508000901969933aea8a08d1ad431db711
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
By not including ASM in the languages for which compiler flags are
adjusted, we can end up with inconsistent optimization and debug
settings between different languages. Make sure they are treated the
same.
Similarly, linker flags for MODULE target types should also have their
debugging and incremental linking flags adjusted, just like EXE and
SHARED targets. When building with MSVC, MODULE targets were having
the relevant flags stripped, but not then replaced with the desired
ones, leaving them empty in typical scenarios. This would primarily
affect plugins, which are built as MODULE rather than SHARED libraries.
Fixes: QTBUG-90237
Change-Id: I648ea74be1654d24cbecc592ce0ca4b59b2ae839
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Make the document reflect the current status of the port.
Also link to https://doc.qt.io/qt-6/build-sources.html and
https://wiki.qt.io/Building_Qt_6_from_Git as official sources
on how to build Qt. This document should IMO rather
concentrate on documenting the build system internals.
Pick-to: 6.0
Change-Id: If62cb966b41b7452edb5b63725756916b66affac
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When building a repository != qtbase, like qtactiveqt, QMAKE_PRL_LIBS
contained entries like Qt6Core and Qt6Widgets, meaning the linker line
would contain exactly these arguments.
When building an activeqt example with qmake, the link then failed with
"LNK1181: cannot open input file 'Qt6Widgets.obj'".
The correct entry would have been $$[QT_INSTALL_LIBS]/Qt6Widgets.obj.
Fix this by determining the full path to the import library in the first
step of the prl generation. This enables QtFinishPrlFile.cmake to
recognize Qt6Widgets as Qt module and generate the right QMAKE_PRL_LIBS
entry.
Pick-to: 6.0
Fixes: QTBUG-90520
Change-Id: Id0d9178da0e0dfc3ea4fadbbe8f5900d792ffc84
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Add '_WINDLL' definition for the MSVC compilers family.
Check the 'FEATURE_optimize_size' value before replacing compiler flags
in the qt_internal_add_optimize_full_flags function. This is required,
because Qt::Core and Qt::Gui modules lost their ability to shrink,
when selecting the appropriate build type or features.
Fixes: QTBUG-89952
Change-Id: I982c25ea84e4793b4006ead0ee516b3f3eb2a054
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Commit d0071a4f87 broke static top-level builds:
CMake Error at .../qtbase/lib/cmake/Qt6Gui/Qt6GuiPlugins.cmake:17 (set_property):
set_property can not be used on an ALIAS target.
Fixed by moving the un-aliasing of the target before the set_property
call.
Pick-to: 6.0
Change-Id: I96c731353798a58ff9b3a664f3614ef03c897dcb
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Projects may call find_package(Qt6 ...) multiple times. When enabling
examples and tests, this happens a lot. For a statically built Qt,
for modules that have plugins (e.g. Gui), every time the module's
config file was loaded, it was generating and adding another copy of
the import plugin sources to the module target. These accumulated and
created many duplicates, which in turn blew out generation time and
made the build very inefficient.
This change checks whether the import plugin sources have already been
processed for the module target and ensures they are only added once.
It records its status on the target itself so that both local and
global targets are supported.
Fixes: QTBUG-90465
Change-Id: I1f45b1ee771a933ee755d44f1e983d6d9113dad0
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This property is dynamically determined and set in the
Qt6${module-name}PluginsConfig.cmake files now.
There is no need anymore to export this property.
Change-Id: I2d164864c4099034b88f9ad852eae8b9f9e55f8b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
When doing a per-repository build of Qt, as it is done for the installer
packages, the build of qtbase has no knowledge of plugins that might be
built and installed from other repositories. That means we must not
write a fixed list of known plugins when exporting Qt modules of qtbase.
In particular, qtsvg adds imageformat plugins that are supposed to be
picked up by qtbase's QtGui module when linking a project against a
statically linked Qt.
${install-prefix}/lib/cmake/Qt6Gui/Qt6GuiPlugins.cmake missed the
include statements for qtsvg's plugin config files and operated on a
fixed list of plugins, all from qtbase.
Apart from that, the Qt6::Gui target's property QT_PLUGINS did only
contain the qtbase plugins.
This patch fixes the situation in the following way:
1. All Qt6*PluginConfig.cmake files in
${install-prefix}/lib/cmake/Qt6Gui are detected and included.
2. From those file names, the target names of the plugins are
deduced. This is safe as the file name of those generated files is a
direct result of the plugin's target name.
3. The QT_PLUGINS property of the module is updated with the detected
plugin target names.
Fixes: QTBUG-89643
Change-Id: Ifc3c39aa9948277ead5ebb209ec5eff64746308b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
