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>
'qt_manual_moc' doesn't provide include paths for 'moc' command to
substitute required macros. This change adds the
'INCLUDE_DIRECTORIES' and 'INCLUDE_DIRECTORY_TARGETS' arguments to
the 'qt_manual_moc' function.
If 'INCLUDE_DIRECTORY_TARGETS' is specified, 'qt_manual_moc'
collects 'INTERFACE_INCLUDE_DIRECTORIES' of provided targets and
uses them as the 'moc' include directories.
Change-Id: I58c8887dae3ca2484574c5e12e2cbd47f5bd3648
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Just like config_module_name is appended by "_private" in the case of
internal module pri, replace module_includes with the private one.
It fixes the issue where a pro file that uses an internal module pri
does not build due to missing paths to private headers.
Fixes: QTBUG-89961
Change-Id: Ice16a1e9f709d29454f1ddf5b954673cc06a88bb
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Jaeyoon Jung <jaeyoon.jung@lge.com>
Make sure to react on failed syncqt runs during the CMake run.
CMake will now report something along this:
```
syncqt couldn't parse .../qt5/qtbase/sync.profile: Can't modify modulus (%) in scalar assignment at .../qt5/qtbase/sync.profile line 25, near ");"
CMake Error at qtbase/cmake/QtModuleHelpers.cmake:192 (message):
Failed to run syncqt, return code: 255
```
Change-Id: I575a5fc926c547b6b633583e5d675f7e35beb734
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When building a Qt module against an installer-provided Qt on macOS, the
module pulls in the headersclean feature that creates the *_header_check
targets. Those targets try to compile the public headers of the module,
and the compilation command contains the -iframework argument. That
-iframework argument is supposed to point to the directory where the Qt
libs are installed. However, it pointed to the original
CMAKE_INSTALL_PREFIX of the machine where Qt was packaged.
Use the QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable instead
that contains the real installation location, even for an
installer-provided Qt.
Pick-to: 6.0
Fixes: QTBUG-90402
Change-Id: I27de8b3cc816488c2716042383b334d5c421452d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Move UNICODE and _UNICODE definitions from the public Qt::Platform
target to the private Qt::PlatformCommonInternal target.
Fixes: QTBUG-89951
Change-Id: Ib4c1c4cab74acda0a43c4ddb3cffd3954393dc89
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Replace package _LIBRARIES by _LIBRARY and _INCLUDE_DIRS by
_INCLUDE_DIR. Move find_package_handle_standard_args for Oracle and DB2,
since this call should set _FOUND variable but not separate condition.
Fixes: QTBUG-89866
Change-Id: I54be2c2c4d7ba4b849a27139702861ecd937c444
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
To be able to link a Release user project against a RelWithDebInfo Qt we
set several IMPORTED_*_RELEASE properties in
the *AdditionalTargetInfo.cmake file of each Qt module.
The EntryPoint module however is a bit special as it is an
INTERFACE_LIBRARY linking publicly against a static
library (EntryPointimplementation). Its *AdditionalTargetInfo.cmake file
was almost empty, because qt_internal_export_additional_targets_file was
called before EntryPointImplementation was set up. Also,
qt_internal_add_module, which calls
qt_internal_export_additional_targets_file, does not know that we want
to export the EntryPointImplementation target.
We fix this by telling qt_internal_add_module(EntryPoint) to not
generate the *AdditionalTargetInfo.cmake file and call
qt_internal_export_additional_targets_file later to take the targets
EntryPoint and EntryPointImplementation into consideration.
qt_internal_add_module learned the option NO_ADDITIONAL_TARGET_INFO to
turn off the generation of *AdditionalTargetInfo.cmake files.
Pick-to: 6.0
Fixes: QTBUG-90039
Change-Id: I68ec7125b538a57567035e7adb8dac3b213f95e6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The QtBuildInternals config package file gets processed before feature
evaluation occurs. That means INPUT_pkg_config may be defined, but the
corresponding FEATURE_pkg_config variable won't have been set/updated
yet. Do this check locally because the availability of a number of
features is conditional on whether pkg-config is available.
Change-Id: I6030eb380ee0c630ffbe5db5eed397a46227c7f6
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add an optional argument to store the report command while feature
evaluation-only stage. This is necessary, because according to the
actual feature evaluation process, evaluation happens only once and it's
impossible to record any command during the evaluation-only stage.
Fixes: QTBUG-90319
Change-Id: I215fbe0a28a2661cd2d97d253b2e2c787d295cbd
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Jason McDonald <macadder1@gmail.com>
Functions in QtFlagHandlingHelpers.cmake try to update the CMake cache
variables for compiler and linker flags. These were using the current
value of those variables and writing the modified ones back to the
cache every time CMake ran. If a toolchain file sets or modifies any of
these variables, that updated value is used and written back into the
cache instead of the original cache variable's value. The next time
CMake executes, the toolchain file re-applies the same change and the
variable grows longer each time with flags repeated. With Ninja, this
causes a complete rebuild every time CMake is re-run. The Android NDK
toolchain file is one example where this behavior is triggered (the
fault is shared, one could argue that the NDK should only be setting
..._INIT variables, but that's out of our control).
Another related bug in the previous implementation was that the flags
used to build after the first CMake execution could be different to
those used for all builds after the second and later CMake runs. This
is because the CMake cache was being updated, but not always the
calling scope of the functions that modified them. If a toolchain file
set any of the compiler or linker flag variables as non-cache
variables, then updating the cache variable would have no effect on
the calling scope. The non-cache variable would continue to take
precedence for that scope for that run. The next time CMake executes
though, the updated cache variable would now have been used by the
toolchain file and the change *will* be part of the non-cache
variable's value.
The above are examples of why you should try to avoid updating these
cache variables from project code. We could leave the cache alone and
always update only non-cache variables, but then a developer looking
at the cache may wonder why the values they see there don't match the
values being used in builds. Or worse, they think the cache values
are being used and don't realize the builds are using something
different. Ultimately, we have to choose which downside we are happy
to live with. The changes here preserve the previous intent of
updating the cache, but it's still a bit fragile.
Fixes: QTBUG-89821
Task-number: QTBUG-85992
Task-number: QTBUG-86866
Change-Id: I8a16753e159bde338e6d2e5dd2ce91fc8ac5c39d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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>
