According to QUIP-18 [1], all build system files
should be BSD-3-Clause.
The files in this patch are part of the build system.
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: Ibc6a60a9b009fab0c953e8e3269533c121e4511e
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
The check and variable name were incorrect after a refactoring.
Amends ba96238600
Pick-to: 6.6 6.7
Task-number: QTBUG-84884
Task-number: QTBUG-90820
Change-Id: I33b6b81695a6352c7869ef6186e00881b47bd6f3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qt_add_qml_plugin has code to set a sensible install rpath for user
project qml plugins.
If Qt was configured without rpath support, we should not add any
rpaths to qt qml plugins:
- qt-computed rpaths added by qt_apply_rpaths
- user-project rpaths added by qt_add_qml_plugin
This is done by setting QT_NO_QML_PLUGIN_RPATH to TRUE as part of
QtSetup, effectively applying the option to any qml plugin that is
built by internal qt api.
User projects will still be able to use the default rpaths added
by qt_add_qml_plugin, even if qt itself was configured with no rpath
support.
Pick-to: 6.7
Fixes: QTBUG-122687
Change-Id: I8178b527553dd00436d0abb3b44061ea16edc121
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This amends commit be009c6857.
The configure option -no-opengl was mistakenly translated to the CMake
argument -DFEATURE_opengl=no. The command line option "opengl" however
is defined as
qt_commandline_option(opengl
TYPE optionalString
VALUES no yes desktop es2 dynamic
)
which is not boolean. And only boolean command-line options may
automagically control features of the same name. It just happens that
the values "no" and "yes" look boolean.
Setting FEATURE_opengl instead of INPUT_opengl broke feature conditions
that check the INPUT_opengl value.
Fix this by checking the type of the corresponding command line option
instead of guessing the type from the INPUT_* value.
An option (e.g. force-asserts) can be diverted to a differently named
input (e.g. force_asserts) with the NAME argument of
qt_commandline_option. In this case, we cannot deduce the option name
from the input's name. To handle this, we store the input's type in
commandline_input_${name}_type and read it when translating feature
values.
Fixes: QTBUG-122914
Change-Id: Ibb4b0633b6635bd2ef6f26ed8f4b19d239bf5854
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The target wrappers for qmake and qtpaths do not work on Yocto
builds and only create confusion when they are available in target.
Add option to disable their generation.
Pick-to: 6.7
Task-number: QTBUG-122420
Change-Id: Ibb829cc846ad6c470fe29e746ade42fccaa33a6f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Qt no longer sets DISABLE_EXCEPTION_CATCHING and can
use the common logic here.
Task-number: QTBUG-121822
Change-Id: If02feafe9eeac49fa2861d2357b358a19e756438
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
This is on by default anyway (see Emscripten settings.js),
and setting it here interferes if exceptions are enabled
by other means.
Fixes: QTBUG-121822
Change-Id: I61d3f1960208e928a4144cff56a0b03c39087a34
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
The function now support two new arguments:
- DEFINITIONS, which allows specifying the custom definitions
- TARGETS, the list of targets thart will be used to collect
the [INTERFACE_]INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS.
Task-number: QTBUG-104898
Change-Id: I3f67537057f91a97597788f1bd4db6904bac6d9c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The AND/OR combinations are not evaluated correctly. Wrap them with
parentheses explicitly to ensure the expected evaluation order.
Pick-to: 6.5 6.6 6.7
Change-Id: Ib2515ba85417b32cef3f799e0cb2c89d2c4257ab
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...according to the Qt 6.7 CMake API review.
Pick-to: 6.7
Task-number: QTBUG-122396
Change-Id: I42012e346325ff05d63fa4dac44276eef15320fe
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This avoids -Wnewline-eof for clang compilers.
error: no newline at end of file [-Werror,-Wnewline-eof]
Q_IMPORT_PLUGIN(Governikus_AnimationsPlugin)
Pick-to: 6.7 6.6 6.5
Change-Id: I8de21f1f27cd177211ebf70fac0e01292cfa410c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The qt_config_compile_test command now assigns the build output of a
config test to the TEST_${name}_OUTPUT variable in the callers scope.
We can use this to show error messages, and it can also be seen in
trace files for better troubleshooting.
It works for all project based calls with CMake 3.16, but for source
code based tests, due to the usage of check_cxx_source_compiles instead
of try_compile, it will only work for CMake 3.23+.
Pick-to: 6.5 6.6 6.7
Task-number: QTBUG-122596
Change-Id: Ib9664c158ba9a391bd17bf30a28f9a34eba991d5
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Better to have something, than nothing at all.
Mention it in the cmake readme.
Task-number: QTBUG-120225
Change-Id: Ieffeeaac714b89d5d8b5a8b0c51abf3fe8e0a6c6
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Replace Qt:: namespace with Qt6:: namespace in target_link_libraries
for the Qt modules/plugins/libraries.
Fixes: QTBUG-114706
Change-Id: Idfd0917dbe1a6a266bc4e9d5f465e550788b5aaf
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Split the header copy custom commands into two blocks and add
<module>_sync_headers_fw_copy target that is responsible for the copy
of CaMeL-case header aliases. For the Ninja generator we leave the
file-level dependencies between the <module>_sync_headers_fw_copy
target and header copy commands. For the Unix Makefiles generator we
put the command directly to the target to make sure it's executed by
make.
Also add the explicit commands for creating the output header
directories.
Fixes: QTBUG-122200
Pick-to: 6.5 6.6 6.7
Change-Id: I71ba716d17a879f20ae0869cf2257d246ac17eff
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Consider QT_HOST_PATH when setting the QT_WILL_BUILD_TOOLS flag.
In this case if we do not crosscompile or require building tools
aka QT_FORCE_BUILD_TOOLS=ON, we may by pass tool_FOUND check and
assume that we will try building the missing tool.
Set qt_require_find_tools GLOBAL property to indicate the tools
lookup requirement.
For tools that can be found we will try re-using them from
QT_HOST_PATH, but not building from scratch.
Change-Id: I94e92f62eb799308e38721b4d580052bb4bb35f9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
According to https://developer.apple.com/support/app-store/ iOS 16
and 17 together cover 89% of devices that transacted on the App Store
on February 4, 2024. And by the time Qt 6.8 is ready, iOS 18
will likely be out or close to being released.
Change-Id: Ice853d0136ee4c697d61add68a996548ac44a0ce
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The default manifest is a minimal file that claims NSPrivacyTracking
false, along with an empty list of NSPrivacyTrackingDomains and
NSPrivacyCollectedDataTypes, as Qt does not generally do user tracking.
Modules can override the default manifest by setting the
PRIVACY_MANIFEST target property, specifying a custom privacy
manifest.
The NSPrivacyAccessedAPITypes key is only required for iOS for now.
Even though we don't build Qt for iOS as frameworks yet, which is
required to embed a privacy manifest, we include the keys for the
APIs we known we use.
Task-number: QTBUG-114319
Change-Id: I654bb52b98ee963adeeb744b35f3a1c2a1270969
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The test system tried to run emrun (No .bat). This failed with a
file-not-found error on windows.
Also there was a test for (WIN32) when deciding to use cmd /c.
This test has been updated to (CMAKE_HOST_WIN32)
Also the aforementioned cmd /c was not present in the test run
output. It has been added.
Fixes: QTBUG-121996
Change-Id: Ib3c053949865038ad43abd479402f5e8e3c015ac
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Since configure doesn't translate -feature-foo to INPUT_foo=ON anymore,
we can remove the code that tries to calculate the feature value from
INPUT_foo.
Task-number: QTBUG-120529
Change-Id: I4829bb634ca8c3f08b489469532b65541d76fa70
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This function calculated the values of the features 'no-prefix' and
'developer-build' from INPUT_* values. Since configure directly
translates -no-prefix and -developer-build to FEATURE_no_prefix and
FEATURE_developer_build, we can remove the function.
Task-number: QTBUG-120529
Change-Id: Ide1fa61af175d8f6a6aa6363dfdfa94912836345
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Inputs (in the sense of configure commandline options) are now
translated to -DFEATURE_foo=ON/OFF if the input name matches a feature
name. This is going to replace more complicated logic in our feature
evaluation.
Task-number: QTBUG-120529
Change-Id: I3ef45cd0e0a1462c53543cd2152eaf7f94318d9d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Directly set the feature variable instead of the INPUT_* variable.
The magic translation from INPUT_* to FEATURE_* is removed in a
subsequent commit.
Change-Id: I8156a20e9af6883783c9a7fa6b4f591d7a2f587c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We now convert the configure arguments -feature-foo and -no-feature-foo
to the CMake arguments -DFEATURE_foo=ON and -DFEATURE_foo=OFF. This is
done, because the former behavior was surprising, and it allows us to
remove quite some code that was needed to calculate feature values from
INPUT_foo and FEATURE_foo.
Task-number: QTBUG-120529
Change-Id: I94f8eb4adbbcaa1090aedce6e711012781c62a3c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Access the target name value, but not use the variable name in
when checking the target existence.
Pick-to: 6.2 6.5 6.6 6.7
Change-Id: I0f86e3c7665d9c028bf4cbdc5aa8fb840fe1d542
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The build tree versioned alias is missing for the GlobalConfigPrivate
target.
Change-Id: I42e9f63363be472e661b656f665e29ea894b7e33
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The argument is inverted GENERATE_CPP_EXPORTS argument. Use it
explicitly for the modules that do not require the autogenerated cpp
exports.
Task-number: QTBUG-90492
Change-Id: Ic67772ba9ed5e40f132a97e7d6844102ad023ff3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
the tests/examples could only be enabled globally. when working on a
specific repo, it's beneficial to disable tests/examples for other
projects to reduce project sizes (and cmake configure/generate times)
Change-Id: I0026ba87b667d427043cc8eb1baa6c28b2046dd7
Pick-to: 6.7
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add the reference to unity builds in the documentation of
NO_PCH_SOURCES to fully describe the semantics.
Change-Id: Icfd3ee401efa154da4b8ed9a307d29f2605d948a
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
It looks like we don't even support nested namespace(RCC namespace
mangling fails). Assuming that QT_NAMESPACE should be
the valid C/C++ indentifier.
Change-Id: I5c2073c21964eb96abb3e894d83e1df65f7730b4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The perivous version generated weird condition, and seems changing
the QT_NAMESPACE after qtbase configuration is noop, we may replace
the generated condition with the conditional generation.
Change-Id: Ifa09dba4db00099a07da2cff5505e6fd0b008289
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This covers the following use case:
QtModuleX is pre-built and installed, it's imported. The plugin has
a PLUGIN_TYPE that is associated with QtModuleX and is built with
application that links QtModuleX. When deploying the application
it's expected that the plugin is deployed, as the one that belongs
to the linked QtModuleX.
This ensures that we udpate the internal _qt_plugins property that
is used in the __qt_internal_collect_plugin_targets_from_dependencies
function.
Pick-to: 6.5 6.6 6.7
Change-Id: I9824351ebab5a24509800da4db69f1e282a35884
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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 a29bff3d80
Amends a0bdd2195f
Pick-to: 6.6 6.7
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>
macOS 11 is at its end-of-life and no longer supported by Apple. It
should be dropped from dev (Qt 6.8).
Task-number: QTQAINFRA-6009
Change-Id: Ib5fc5adbc13eb08e4603b226b9d7748417765b15
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Bundled 3rdparty libraries link Qt platform targets implicitly, which
lead to the dependency resolution when the library is used by another
targets. For qtbase this works just fine since all platform targets
are not imported and they are used from a build tree. But in case if
3rdparty library is built as part of Qt repo different from qtbase
platform targets are imported and trigger the global promotion in
CMake. Usually qt_find_package for the 3rdparty libraries is called
somewhere in src/... directory and since Qt::Platform* targets are
already created in the top-level repo CMakeLists.txt by the
find_package(Qt ...) call, this leads to an error.
The propsed fix forces the global promotion of Qt platform targets
as soon as they created by the one of the initial find_package(Qt ...)
calls.
Change-Id: Iceb53f9ecccbdc438f9bc3bcc836583cfd4de535
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_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.2 6.5 6.6 6.7
Fixes: QAA-2266
Change-Id: Ifc616e26a00674371c8e2fe2ca12237d153e5707
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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 48841c34d2
Amends 8c912cddeb
Pick-to: 6.7
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>
Previously we only warned about unsupported cmake generators when
configuring qtbase.
Now we do it for other submodules as well.
Pick-to: 6.7 6.6 6.5
Task-number: QTBUG-120602
Change-Id: I9d78db546bcf1238604362b248d41d4516b60b2a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The QT_INSTALL_DOCS is configured with incorrect path sometimes,
especially while configuring qtbase with QT_HOST_PATH,
which also lets you build documentation for the essential modules
such as QtCore, QtGui, and so on. If the default QT_INSTALL_DOCS
path is wrong, a way to override the path would enable building
documentation for the essential modules without having to build
parts of qtbase.
Change-Id: I686e0bc103f9722aa98f3c02d2a5af9e645cc9d9
Done-with: Topi Reinio <topi.reinio@qt.io>
Task-number: QTBUG-121459
Pick-to: 6.7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The current implementation of the API accepts only two
arguments, {target} and {qdocconf}. It passes a few
environment variables to build targets, providing info.
about the Qt version being used. QT_INSTALL_DOCS is one
of these environment variables, and it is the install
path for all the Qt module/addon documentation sets.
QT_INSTALL_DOCS is also the path where the global QDoc
configuration files are available.
If a project uses the qt_internal_add_docs to create
the build targets for the documentation, and the Qt
version used to configure the project is a pkg installed
using the qt-online-installer, the QT_INSTALL_DOCS path
is always wrong. Such projects should either maintain a
CMake setup for documentation or configure and
build Qt from source with the correct QT_INSTALL_DOCS
path, which is then passed to qdoc.
This change enables passing additional indexdir
and other arguments to QDoc, which is useful. For example,
if QDoc cannot find all the cross-module link targets,
you could either pass extra indexdir argument to resolve
the links or turn off the link errors.
For example, if your qdocconf has the following depends
entry to enble linking to other modules:
depends += qtcore qtmultimedia
And the documentation for these modules are not part
of the Qt installation used to build the projects, you
could pass additional index dirs to enable cross-module
linking.
qt_internal_add_docs{target_name qdocconf
INDEX_DIRECTORIES /absolute/path/Qt6/Docs /one/more/Qt6/Docs /another/Qt6/Docs)
Change-Id: Ieac271ddf92990d722602487c41af7f18546d096
Done-with: Topi Reinio <topi.reinio@qt.io>
Task-number: QTBUG-121457
Pick-to: 6.7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qtgraphs defines a target in one directory, and then calls
qt_internal_extend_target with NO_UNITY_BUILD_SOURCES in another
subdirectory scope. That in turn calls set_source_files_properties
but only for the latter subdirectory, and not the main target
directory.
Because CMake has per-directory-scope source file properties, the
'no unity sources' option was effectively ignored.
When using CMake 3.18, make sure to specify the TARGET_DIRECTORY
option so that the source file properties are added to the scope of
the defining target.
Pick-to: 6.5 6.6 6.7
Change-Id: I4190d4073a2955aa7053b5faaaa57f683bc768a2
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
IMPORTED targets obviously have nothing to sync. So we should ignore
them when collecting dependencies for header sync.
Pick-to: 6.5 6.6 6.7
Change-Id: Ief68ff5eb2eb13a3fe1608445e8f5e6abb5971b4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When the user:
- has a non-developer-build -debug-and-release Qt
- and tries to configure the sqldrivers project with
-DCMAKE_BUILD_TYPE=Debug
our build system discarded the user request, and defaulted to
'Release'.
That happens because CMake sets CMAKE_BUILD_TYPE_INIT to 'Debug' by
default on Windows-MSVC, and we have no marker to differentiate
that the 'Debug' value was user-specified.
We have such a marker
- via the
__qt_auto_detect_cmake_build_type_before_project_call variable
when configuring qtbase / top-level qt
- via the
__qt_toolchain_cmake_build_type_before_project_call variable when
configuring via the qt toolchain file (although that doesn't apply
when configuring a multi-config build for obscure reasons, which
should be addressed).
A conservative fix is to add a new variable / marker called
__qt_internal_standalone_project_cmake_build_type_before_project_call
which the 'sqldrivers' project will set with the build type that is
detected before the first project() call, and use that to decide
whether to override the build type, similar how we do with toolchain
file variable.
We could reuse one of the previous variables, but I figured it's better
to be explicit with a new one. And hopefully we can clean up the whole
logic in a follow-up commit.
Amends 48841c34d2
Amends 8c912cddeb
Pick-to: 6.5 6.6 6.7
Fixes: QTBUG-120436
Task-number: QTBUG-114958
Change-Id: I37e3d8041088fe6084a9976ecc80ddd62d73ef81
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Mitch Curtis
Giuseppe D'Angelo
Lucie Gérard
Alexandru Croitor
Joerg Bornemann
Samuli Piippo
Tor Arne Vestbø
Morten Sørvig
Alexey Edelev
André Klitzing
Lorn Potter
Kai Köhne
Even Oscar Andersen
Tim Blechmann
Elias Toivola
Venugopal Shivashankar