This is necessary to be able to find Qt6 modules in CMake
ExternalProjects before Qt is installed, regardless of top-level or
per-repo builds.
One use case is examples that are built as ExternalProjects.
Pick-to: 6.2 6.3
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: Ic6a9bfd1c52a04e34b221deab40f419a6fee9463
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Use IMPORTED_LOCATION of rcc target when generating Android
deployment settings, instead of the hardcoded host path.
Introduce a helper function to find the location of the imported tool
target.
Change-Id: Icfa51ee7a01b3f58fc4892da03055f9ed531cc0b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
A single global QT_REMOVED_SINCE will start hurting us once more
modules downstream of QtCore start using the mechanism.
With every use of feature, the set of code that needs to compile under
QT_BUILD_REMOVED_API increases. Since we use QT_REMOVED_SINCE in
situations where overloading the new and the old function don't work
in general, this means all code included by any removed_api.cpp needs
to be very carefully written to ensure that any calls to the overload
set formed by the combination of old and new function(s) don't create
ambiguities.
Likewise, the set of APIs that change semantics under
QT_BUILD_REMOVED_API also increases. At some point, the combination of
removed_api.cpp including almost every module header and almost every
header exposing source-incompatibilities when included in
removed_api.cpp will make maintenance a headache.
By making QT_REMOVED_SINCE and QT_BUILD_REMOVED_API per-module
(QT_CORE_REMOVED_SINCE, ...), easy now that we generate the export
macros using CMake, we limit the scope of this problem to the module
using the feature. Downstream modules (say, QtWidgets) will now see
the QtCore API like every other user, even in the
widgets/compat/removed_api.cpp TU.
Pick-to: 6.3
Change-Id: I177bc7bd5aa8791639f97946c98e4592d2c7f9d9
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We were passing the full option from the user as a single string in the
command-line to the compiler.
clang++ -c "-O3 -g1 -march=tigerlake -mprefer-vector-width=256 -maes" [...]
error: invalid integral value '3 -g1 -march=tigerlake -mprefer-vector-width=256 -maes' in '-O3 -g1 -march=tigerlake -mprefer-vector-width=256 -maes'
Pick-to: 6.2 6.3
Fixes: QTBUG-100315
Change-Id: I6fcda969a9e9427198bffffd16ce83150d4e4263
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Restore the 'QT_NO_JAVA_STYLE_ITERATORS' and
'QT_NO_NARROWING_CONVERSIONS_IN_CONNECT' definitions for Qt
targets.
Add the function that adds global definitions for Qt targets according
to the provided scope and the target property-based switch to disable
the definition for a specific target.
Pick-to: 6.2 6.3
Task-number: QTBUG-100295
Change-Id: I28697e81f9aabc45c48d79aae1e5caea141e04e1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The package is called mit-krb5-gssapi on Ubuntu, and the LIBDIR variable
was missing an underscore.
Pick-to: 6.3 6.2
Change-Id: I85b5603c1161f33462aa71bbd522d40dd7489405
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
1. Clang-CL can't recognize "/d2FH4" and it's causing
lots of warnings when compiling. So don't apply it
when building with clang-cl.
2. The definition of "FS_INFORMATION_CLASS" need to
be visible to clang as well. Don't know why it was
excluded originally.
Pick-to: 6.3
Change-Id: I7b6e14999eea0ba1f0d73962ff03a35548f88a5a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
This will show the CMAKE_BUILD_TYPE that was computed for a configured
repo or standalone tests, after the logic in
QtBuildInternalsExtra.cmake is executed.
Pick-to: 6.2 6.3
Change-Id: Ib8ffa2c7806a4c16385a2fcd4500f8a0f6a9aa88
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We need it for shadertools.
Change-Id: I9e9c76e535e5cd698564b48beedb7380b08173e2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Simeon Kuran <simeon.kuran@gmx.at>
The mold linker is a new linker for Linux that provides faster link
times compared to BFD ld, ld.gold and lld.
It can be found at https://github.com/rui314/mold
To build Qt with mold, ensure that the binary in your PATH and then
configure Qt with with either
cmake /path/to/qtbase -DINPUT_linker=mold
or
/path/to/qtbase/configure --linker mold
The change was tested with gcc 9, clang 10, clang 12, mold
1.0.0. Only qtbase and qtdeclarative (and dependencies) were tested.
Pick-to: 6.2 6.3
Task-number: QTBUG-99270
Change-Id: I2e64a1f4257c37ff5b64a9326e548b9b46e07c80
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Minor glitch in wording, but it's been bugging me for months.
The meaning of "try to remove [a file]" implicitly says you might be
unable to do so; while the attempt might help with your situation, the
experiment might merely be a diagnostic, e.g. because if you can't
remove the file, that would imply things that would help you solve
your problem. For contrast, "try removing [a file]" says removal
might actually solve the problem for which this action is proposed as
a fix.
Change-Id: Ic995cfdef1523094bb368dcda8bd0d2bbd2e9434
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Because that's what it is.
Change-Id: Ib42b3adc93bf4d43bd55fffd16c144ef04d68d83
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add a "HURD" CMake platform specification, so it can be properly
checked in the build system.
Set QT_DEFAULT_MKSPEC to the existing hurd-g++ mkspec.
Hurd supports $ORIGIN in RPATH, so enable it.
Hurd uses X11, so add it to the X11_SUPPORTED list.
Enable few more feature checks that apply to Hurd as well: either
because they are provided by GNU libc itself, or because they are
implemented on Hurd.
Check and set the ELF interpreter, as it is a common functionality of
the GNU toolchain.
Change-Id: Id347033560bbc5a2a4e2c3abb493c948c002b40e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The version script compile test did not use the linker that the build
system determined to use to link Qt, but rather the system linker.
Run qt_run_linker_version_script_support only after the global qtbase
features have been evaluated and make sure to include the active
linker flags.
Pick-to: 6.2 6.3
Change-Id: I0ff82406828daaf0dc5ec25a55f53ac7d98e3347
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Previously we passed flags like -ld-fuse=lld only to compile
calls, but not to the link call of a compile test project.
Make sure to pass it to the link call instead by using
check_cxx_source_compiles + CMAKE_REQUIRED_LINK_OPTIONS
instead of
check_cxx_compiler_flag.
Note the flag that is passed is still via passed via the
compiler launcher and not directly to the linker.
Remove duplicate flag handling code.
Pick-to: 6.2 6.3
Change-Id: I1bf90573904a9df83240b6debfee3cc9e425c6bb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The generated dbus headers would not appear in IDE source lists
because of incorrectly named variables.
Pick-to: 6.2 6.3
Change-Id: I276d4284eb94b98cc75f791de62ca332ad947004
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Same treatment as is given to GCC further below.
Pick-to: 6.3 6.2
Change-Id: I3762c39a0b5d9add365ecf828b80d3ba432578c2
Reviewed-by: Fabian Kosmale <fabian.kosmale@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>
Use “-pthreads” instead of “-s USE_PTHREADS=1”. This
is both a compile and linker option.
Pick-to: 6.3
Change-Id: Iaf7cb4ec41577fe596c3e81fda05c03fe0074c08
Reviewed-by: David Skoland <david.skoland@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
When compiling CUDA sources in a user project, the Qt6::Platform target
would pull in C/C++ related compiler flags, leading to compiler errors.
Make sure that we only add those flags to C/C++ source files.
Pick-to: 6.2 6.3
Fixes: QTBUG-99548
Change-Id: Idbccd65fe8f66abd1da3fce95e563065d1ed3cc6
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Add '-bigobj' for MSVC and '-Wa,-mbig-obj' for MINGW to the
PlatformCommonInternal compiler options.
Pick-to: 6.3
Change-Id: I706b83d189a116a3ab6f93d59593e237e66b0e2e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since f19ce3898e we link OpenSSL to
QTlsBackendOpenSSLPlugin instead of QtNetwork itself. In dependent Qt
repositories this leads to the following situation:
QTlsBackendOpenSSLPlugin's dependencies call
find_dependency(WrapOpenSSLHeaders), and OpenSSL_FOUND is set to ON in
that scope. Later, we call find_package(WrapOpenSSL) in a different
scope. find_package(WrapOpenSSLHeaders) bails out early, because the
target WrapOpenSSLHeaders::WrapOpenSSLHeaders exists.
find_package(OpenSSL) is not called again. The check for OpenSSL_FOUND
fails, because the variable is not visible in the scope of
FindWrapOpenSSL.cmake, and we don't create the WrapOpenSSL::WrapOpenSSL
target.
Fix this by checking for the existence of the target OpenSSL::SSL
instead of the OpenSSL_FOUND variable.
Pick-to: 6.2 6.3
Fixes: QTBUG-99623
Change-Id: Idd0e8a60fabd0c7772413d557442c0012b0b436c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Script that wraps Qt test execution in order to iron-out flakiness.
Task-number: QTBUG-96353
Change-Id: Ie8ee780e3f4f8d086c080a7784f9f68fd1867be2
Reviewed-by: Daniel Smith <Daniel.Smith@qt.io>
CMake versions less than 3.19 don't support adding the source files to
the PRIVATE scope of the INTERFACE libraries. It looks like these
PRIVATE sources are only used by IDEs to display them in a project
tree. Skip them to avoid configuring issues.
Fixes: QTBUG-99316
Pick-to: 6.3
Change-Id: Id03f540ac9c94e920adfae5de4f364bd7aba4613
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This change tries to make the API more user friendly and prevent wrong
use of multi-abi API. ANDROID_ABI argument of qt6_add_executable was
position-depend and needed to be placed after the executable 'sources'.
Using the target property we solve this problem and provide more
consistent and common way to enable multi-abi build for the single
target.
This meanwhile also requires to execute multi-abi build configuration
in the finalizer, since the property might be set at any point.
Also the priority of the QT_ANDROID_ABI target property now is higher
than the priority of the QT_ANDROID_BUILD_ALL_ABIS variable. So target
will only build packages with the ABIs specified in QT_ANDROID_ABI
property if both are set.
Pick-to: 6.3
Task-number: QTBUG-88841
Change-Id: I3515297ed267974498913c59619433dc234ec217
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Set ${FWCryptoTokenKit} when the framework has been found.
This is useful for WIP card reader support in QtConnectivity.
Task-number: QTBUG-97946
Change-Id: I0e85e0fd2e0fc45fb3069bbdaa2d8b2c927a6c2d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Qt's WinRT support was removed long time ago.
Change-Id: I60b220e970072c3450e3793862d6f68801d2b5b3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The result variable was expanded at configure time rather than at
script execution time due to missing escaping.
A tidbit of information, the result variable can contain not only an
exit code, but a string as well.
For example on arm macOS with a crashed test it contains
'SIGTRAP'.
Curiously if the crashing executable is executed directly without
CMake, 'Trace/BPT trap: 5' is shown instead, perhaps because of
the shell.
Amends 3ef6af024b
Pick-to: 6.2 6.3
Change-Id: I50e57922abfc6eccde205c6252eebfda510bad41
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This amends commit 0bea727cac or rather
reverts it and applies a different fix for QTBUG-98843.
Use file(WRITE) instead of configure_file or file(CONFIGURE). This
command doesn't have the line endings issues in CMake 3.19 (see
QTBUG-98843). It's not problematic that the .bat file gets a new
timestamp on every configuration step, since we don't add dependencies
on it.
Fixes: QTBUG-99223
Task-number: QTBUG-98843
Change-Id: Ibdcd0e4703bf6df42c6a6d0bb2f35c5144bbe30a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This might give a few insights into why the process has failed, at least
if distinct return values are used for different errors.
Change-Id: I61fe0ede812c4dda3d0cf0f2c96a479d198d340d
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Package global data in COMDAT sections for optimization.
According to the docs, this can significantly reduce the
size of the resulting binary executable.
I've tested build Qt with /Gw locally with and without
LTCG, the result shows /Gw can reduce the binary size
indeed, but not "significantly". The result also reveals
that exes can benefit much more from /Gw than dlls.
The result can be seen from the QTBUG-98894 bug report.
Microsoft Docs:
https://docs.microsoft.com/en-us/cpp/build/reference/gw-optimize-global-data?view=msvc-170
Task-number: QTBUG-98894
Change-Id: Ibce34c98e791e519d669a5fe39c0027d1459c382
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
When building Qt we want to use the highest available 'target' SDK
version. If the version of the available SDK is lower than the minimum
required 'target' SDK version, we need to throw an error.
Pick-to: 6.2 6.3
Fixes: QTBUG-99165
Task-number: QTBUG-98870
Change-Id: Ib75567a6f33ac6d23d9f79e8ed8535839c08b91d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qt_setup_tool_path.bat did not have proper line endings on Windows with
CMake 3.19, breaking the invocation of tools that use the wrapper, for
example qmltyperegistrar.
The reason was that file(CONFIGURE) doesn't properly write line endings
with CMake 3.19. See upstream issue #21769.
Use configure_file with a proper input file to work around this issue.
Pick-to: 6.2
Fixes: QTBUG-98843
Change-Id: I2a4da15f306dc844cf83ca9721a77196c42af2ad
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
-g4 was deprecated in Emscripten 2.0.17, and since we are well past
that version we can safely use -gsource-map instead.
Change-Id: I497155619d6320661f6be0e220b52fa7d6ca0b8e
Reviewed-by: David Skoland <david.skoland@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
[ChangeLog][wasm] Recommended emscripten version is now 3.0.0
Change-Id: I9ae082509415d8f00b8e9970b730ad4a472da310
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Visual Studio 2019 introduced the dubbed FH4 feature
which can make C++ exception handling smaller on x64.
According to the article [1], it's enabled by default
for UWP applications, and Microsoft also use it in
their own widely-known commercial products such as
Office to reduce the binary size.
So make use of this feature for Qt when possible, to
get smaller binary.
As a drive-by, add "/EHs-c-" explicitly to the flags
when we want to disable C++ exception handling.
[1] Official article that introduces dubbed FH4:
https://devblogs.microsoft.com/cppblog/making-cpp-exception-handling-smaller-x64/
Change-Id: I2e3330de477f78372cf7903d0ef7a732b09552a9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: André de la Rocha <andre.rocha@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Building against a static debug MSVC Qt produced LNK4099 warnings (PDB
was not found with object file).
This was because we did not install the .pdb files for the object
libraries that are created for Qt resources. Now, these .pdb files are
named like the object library targets and are installed next to the
object files.
Pick-to: 6.2
Fixes: QTBUG-97699
Change-Id: I7e23f8392b7ac657be1d2fb3b33e051ae2e4d407
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
...if an Android platform < 10 is installed.
The existing platform detection code preferred android-9 over
android-31, because the sorting did not use natural comparison.
Natural comparison was added to CMake in version 3.18. We simulate this
feature for older CMake versions.
Pick-to: 6.2
Fixes: QTBUG-98726
Change-Id: Ib2eb87bd47220feb672275fa5203df4f2b6d7ca7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Like Q_NAMESPACE_EXPORT for Q_NAMESPACE, this variant of Q_GADGET
allows passing an export macro. This is useful to avoid exporting the
whole class just to get the staticMetaObject hidden therein exported.
Before anyone asks: No, we don't need Q_OBJECT_EXPORT, because QObject
subclasses, being polymorphic, always need to have a class-level
export macro (to export their vtable), but while that technique also
works for value classes (the Q_GADGET audience), it is not desirable
for them, because it makes inline functions exported in Windows debug
builds, which is not what we want, because it needlessly restricts
what you can to with the inline functions (e.g. remove).
[ChangeLog][QtCore] Added the Q_GADGET_EXPORT macro, which is like
Q_GADGET, but allows passing an export macro (like Q_NAMESPACE_EXPORT
for Q_NAMESPACE).
Fixes: QTBUG-55458
Change-Id: I546297de1e8aa45d83381991bcd3fbca61e1eef0
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
When building for and running the '_check' target in Android we need
to make sure that target apk is assembled and ready for deployment.
Pick-to: 6.2
Change-Id: Ifc63aac230f0bb8375d319ec443174c5a436485e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Large address aware is enabled by default in 64-bit
compilers, but not 32-bit compilers. But Qt users
may build 32-bit Qt themself, in this case large
address aware is disabled in fact, and it may cause
some issues. So we pass /LARGEADDRESSAWARE to the
linker unconditionally to make sure large address
aware is enabled for both 32-bit and 64-bit builds.
Microsoft Docs:
https://docs.microsoft.com/en-us/cpp/build/reference/largeaddressaware-handle-large-addresses?view=msvc-170
Change-Id: Idb2603d9ba0ba9ef4477ce1c3174b7c7e8ba76f6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Not a compile option, and also added to the linker
options above.
Change-Id: Iab2107d4b5ee4bc73e85b3cd5070f1a96b3a5a3b
Reviewed-by: David Skoland <david.skoland@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
- GHS compiler doesn't have -Wextra flag and it leads to huge count of warnings.
Pick-to: 6.2
Change-Id: Id2ba654a49fb163bebc75e3a22ecaa1895ecdbe8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In preparation for addition of new baseline tests, establish a new
test category, "baseline". This is similar to the category
"benchmarks" in that it contains tests that use the QTest framework,
but conceptually are not unit tests, in contrast to those under auto/.
Move the existing QPainter baseline test, tst_lancelot, into this new
category, and rename it accordingly.
Baseline tests use the QBaselineTest extension to QTest. Move that
extension too into the tests/baseline directory, allowing the clean
out of the baselineserver directory.
Pick-to: 6.2
Change-Id: I1b527f5867c953b1d22be73798fcf7d1494712ea
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
To allow using Android 12 APIs.
Pick-to: 6.2 5.15
Change-Id: I5e9da66c84457888ec723125d16876891232a99b
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This amends commit c5409964b0.
When detecting a variable assignment, we must ignore arguments that
start with a dash. Otherwise, arguments like --prefix=~/Qt are ignored.
Change-Id: I3b143113b94ca0d8af92679c1f567fbcec298349
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The Qt bluetooth module uses ${FWCoreBluetooth} when building for iOS,
but that evaluated to empty.
Pick-to: 6.2
Change-Id: I93ff2c30697a912bed454087ae260fae9cc41b0f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We can technically build without Xcode, as long as the command line
tools are installed. We reflect that by an empty QT_MAC_XCODE_VERSION
variable.
Pick-to: 6.2
Change-Id: I40ffa28a628157e0a2c63656065ea7c41a680e01
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And bump NTDDI_VERSION to 0x0A00000B (NTDDI_WIN10_CO) at the same time,
to unblock the developers from accessing the latest Windows APIs.
Pick-to: 6.2
Change-Id: Ifbc28c8f8b073866871685c020301f5f20dc9591
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A top-level non-developer build is supposed to default to a prefix like
"/usr/local/Qt-6.3.0". That wasn't the case.
In QtSetup.cmake we check CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT,
set CMAKE_INSTALL_PREFIX and did the same thing later in
QtBuildInternalsExtra.cmake, with a different value. Make sure we run
the latter code only in per-repo builds.
Pick-to: 6.2
Fixes: QTBUG-98087
Change-Id: I4a1291dfd126aa11c21d69809f2cf7b075c98d2e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The qtpaths tool is supposed to replace "qmake -query", and it must be
available for cross-builds as a wrapper script like qmake.
Re-use the existing facility for creating the qmake wrapper script for
creating the qtpaths wrapper script.
Pick-to: 6.2
Fixes: QTBUG-97821
Change-Id: I460bae61a531994422e1c0fba09c79e4aa65713f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's now possible to call configure with arbitrary variable assignments
"FOO=BAR" that get passed as "-DFOO=BAR" to CMake. There is no error
anymore for unknown variables. CMake already warns about those:
"Manually-specified variables were not used by the project: FOO".
[ChangeLog][configure] Users can directly assign CMake variables with
configure, for example "configure CMAKE_CXX_COMPILE=clang++-11".
Fixes: QTBUG-88210
Change-Id: Ib15e63a895df717919dd2b6623fa4d284209776f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Some apps may need more initial memory when linking, emscripten will
fail with:
wasm-ld: error: initial memory too small
This increases the default initial memory form 16MB to 20MB.
Larger apps might still get this error, in which case
QT_WASM_INITIAL_MEMORY can be set.
Pick-to: 6.2
Fixes: QTBUG-97457
Change-Id: Icdc56c41fb3a3852a9a83f7a3dc15820e83e1148
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Misc. fixes, including:
Fix a couple of typos in the JavaScript code. Also, macros-
within-macros don’t work, (without resorting to preprocessor
token pasting), so remove the debug output for now.
Limit the exec() “simulateInfiniteLoop” workaround to
top-level application exec() only. This way, asyncify
can be used for nested QEventLoop::exec() calls. (Emscripten
supports one level of suspend only, so we don’t want
to use that for the top-level exec(), but instead use it
for dialogs and such).
Use the new QEventLoop::ProcessEventsFlag::ApplicationExec
enum value to detect the exec() call type.
Change-Id: Ic702bfc31faf2e9f84ac5d3ccf43d067c5c61bf0
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
The qt_finalize_framework_headers_copy function uses the module
QT_COPIED_FRAMEWORK_HEADERS property to generate the dependency list
for the ${target}_framework_headers target. In a common case elements
can be added to the QT_COPIED_FRAMEWORK_HEADERS property after the
qt_internal_add_module command call, that's why we need to make sure
that qt_finalize_framework_headers_copy is called after collecting all
headers assigned to the module.
Pick-to: 6.2
Change-Id: I2878fa6b8d4b11677c3f48345bf6e239221074c2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
To be consistent with prepare_qdoc_args.
Pick-to: 6.2
Change-Id: Ibd40d6c26f6f6fa49ea78b6476f396153b7c4ee5
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
If one of the dependencies in QtFooModuleDependencies.cmake is not
found, QtFoo_FOUND will be set to False by find_dependency.
In that case, we should not create imported targets that belong to
that package.
It would be misleading for projects that do target existence checks
instead of package_FOUND checks as well as generally being
incorrect. The created imported targets might be referencing other
targets that would not exist.
Pick-to: 6.2
Fixes: QTBUG-97896
Change-Id: I09198aa3f19be047b27c29329b6e62c30fa09dc0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Craig Scott <craig.scott@qt.io>
The function qt_commandline_assignment and everything related to it is
removed from configure. It was only used in qtbase, and all usage has
been removed.
More general variable assignments will be added in a subsequent commit.
Task-number: QTBUG-88210
Change-Id: I7cfa782e89914f2b0dc0277c46e425c8a825557e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's been deprecated since Mac OS X 10.5.
qmake templates fixed in 0768a28fbf.
Task-number: QTBUG-74872
Pick-to: 6.2
Change-Id: If7d988f27f07b6fa095b2ea51a87c306361d63d1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's been there for ages, we may as well use it and remove unnecessary
complexity from CMake.
Pick-to: 6.2
Change-Id: I2bbf422288924c198645fffd16a9742567a7e4af
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
CMake's Modules/Platform/Android-Initialize.cmake was setting
CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH to OFF and host perl was not
picked up in PATH on Windows when building for Android.
Pick-to: 6.2
Change-Id: Ic98d8b38425231ef6aaf173fdfe958b573cc0c40
Reviewed-by: Craig Scott <craig.scott@qt.io>
One can now pass -DQT_REQUIRE_HOST_PATH_CHECK=OFF or
-DQT_REQUIRE_HOST_PATH_CHECK=ON to force disable or enable
the QT_HOST_PATH and QT_HOST_CMAKE_DIR_PATH validity checks.
One potential use case is if a project wants to manually find
QtFooTools packages by manipulating CMAKE_FIND_ROOT_PATH and such,
in which case they might not want to pass a QT_HOST_PATH.
Another potential use case is cross-building Qt with
-DQT_BUILD_TOOLS_WHEN_CROSSCOMPILING=ON and allowing the same
generated toolchain file to be used on the device image.
By default the generated toolchain file would require a host path
because it expects that it's still being used for cross-compiling.
But once the toolchain file is deployed to the device there's no need
to use the host tools anymore.
Another use case is building a desktop Qt using the host tools of
another desktop Qt. The new desktop Qt can use its newly built tools
just fine and wouldn't need the original desktop Qt tools.
QT_REQUIRE_HOST_PATH_CHECK needs to be added the list of vars to pass
through to try_compile calls.
Change-Id: I4b922b5d854828e6b9210dd8c07b4b1b8630aad1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Craig Scott <craig.scott@qt.io>
The environment variable check to set extra env vars
was using invalid syntax. The condition always resolved to TRUE
which means the env vars were constantly re-assigned inside each
try_compile project.
To check for undefined-ness, one can use if(NOT DEFINED ENV{...})
To check for false-ness, one can use if(NOT "$ENV{...}")
To check for string emptiness, one can use
if(NOT "$ENV{...}" STREQUAL "")
In this particular case checking for false-ness is good enough.
The extra re-assigning had no visible effect, so this is just cleanup.
As a drive-by, clarify one comment.
Amends ca59c20939
Pick-to: 6.2
Change-Id: I8fd400101efa9e610a81268c33cac8c0cb33cba3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Craig Scott <craig.scott@qt.io>
Instead of hard-coding a lib/cmake suffix to CMAKE_PREFIX_PATH
use the parent directory of the Qt6HostInfo package which is always
searched for when QT_HOST_PATH is set.
Amends d2359b2d4e
Pick-to: 6.2
Change-Id: I7f3c8fe17bc82f733580d68d928146434a57d849
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Previously when one wanted to use a cross-compiled Qt with a host Qt
installed in a non-default location, they'd have to provide both
QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR.
This change will now try to first check if ${QT_HOST_PATH}/lib/cmake
is a valid path on disk and use that. This is nicer to the user
because they don't need to specify 2 paths anymore.
Furthermore the path computation and sanity checks are now done after
any extra toolchain cmake files are loaded, to give an opportunity
to the files to set the paths first.
Finally, both variables need to be added to
__qt_toolchain_used_variables so they are passed along to try_compile
calls if the variables are specified manually.
Otherwise when the toolchain file is loaded by a try_compile project,
it will error out saying no host path found (as long as the initial
paths embedded in the toolchain are invalid).
Amends 93fc3afe71 and
ec90f9013b
Pick-to: 6.2
Change-Id: I433239b36b084f2d0a7a0dd043fdf87d77c138f3
Reviewed-by: Craig Scott <craig.scott@qt.io>
One can now set QT_FORCE_FIND_TOOLS to ON together with passing a
QT_HOST_PATH to ensure that a new desktop build uses
already existing tools from a different Qt host (desktop) installation.
Depends on a0e56294c1
to work, which is not in 6.2, but this change is still included in
6.2 because it cleans up the conditions a bit to make them more clear.
Amends 42d3b21c92
and 5a779a4ad3
Pick-to: 6.2
Fixes: QTBUG-95099
Task-number: QTBUG-97658
Change-Id: If6258fb1091c6c1e457f22ae5f468b811bd20d57
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When cross-building, qt_internal_add_tool would accidentally find device
QtFooTools CMake packages as a result of calling find_package. It should
have found host Tools packages instead.
The reason was due to a combination of setting
CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to BOTH, find_package preferring
the lookup of packages in CMAKE_FIND_ROOT_PATH before CMAKE_PREFIX_PATH
and there being a Tools package in the device sysroot.
Because qt_internal_add_tool didn't adjust CMAKE_FIND_ROOT_PATH to
contain the host path, the device package was picked up.
Change the implementation not to set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
and instead modify both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH
to prefer the host packages instead.
This aligns to the behavior that was introduced in
ec90f9013b
which is used in QtModuleDependencies when looking for Tools packages.
Pick-to: 6.2
Fixes: QTBUG-97599
Change-Id: I8e38284774ae97981ccfd5071465609f3de80f01
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When building Qt repos, all find_package(Qt6) calls request a
PROJECT_VERSION version which is set in .cmake.conf via
QT_REPO_MODULE_VERSION.
This means trying to configure qtsvg from a 6.3 branch using a
6.2 qtbase won't work, because qtsvg will call find_package(Qt6 6.3)
and no such Qt6 package version exists.
There are certain scenarios where it might be useful to try to do
that though.
One of them is doing Qt development while locally mixing branches.
Another is building a 6.4 QtWebEngine against a 6.2 Qt.
Allow to opt out of the version check by configuring each Qt repo
with -DQT_NO_PACKAGE_VERSION_CHECK=TRUE. This setting is not
recorded and will have to be set again when configuring another
repo.
The version check will also be disabled by default when configuring
with the -developer-build feature. This will be recorded and embedded
into each ConfigVersion file.
If the version check is disabled, a warning will be shown mentioning
the incompatible version of a package that was found but that package
will still be accepted.
The warning will show both when building Qt or using Qt in a user
project.
The warnings can be disabled by passing
-DQT_NO_PACKAGE_VERSION_INCOMPATIBLE_WARNING=TRUE
Furthermore when building a Qt repo, another warning will show when an
incompatible package version is detected, to suggest to the Qt builder
whether they want to use the incompatible version by disabling the
version check.
Note that there are no compatibility promises when using mixed
non-matching versions. Things might not work. These options are only
provided for convenience and their users know what they are doing.
Pick-to: 6.2
Fixes: QTBUG-96458
Change-Id: I1a42e0b2a00b73513d776d89a76102ffd9136422
Reviewed-by: Craig Scott <craig.scott@qt.io>
Tests for QNX are run in qemu over ssh and setting WORKING_DIRECTORY
will cause created test wrapper to try change specified directory
which will fail (expects local directory) when test is invoked over
ssh.
Task-number: QTBUG-87628
Pick-to: 6.2
Change-Id: If991002398811cc9cb9cbac54da5d2cb0d8c3589
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
GNetworkMonitor can get information from 3 sources:
* org.freedesktop.portal.NetworkMonitor
* NetworkManager
* netlink
Change-Id: Icfafe6af42148f26360449f1262093ffc6b0613a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The previous implementation would pick up static Qt deps of a
shared Qt library as packages to find, but packages are not
created for these static libraries in a shared Qt build.
For example Qt::BundledSpirv_Cross is a static helper lib
that is linked directly into ShaderTools shared lib and no CMake
package is created for it, so we shouldn't look for it.
Separate the code path to filter out private dependencies
of a shared library target that don't have packages.
Amends 87215c70c0
Pick-to: 6.2
Fixes: QTBUG-97673
Task-number: QTBUG-86533
Change-Id: I43490b4d20c150256ccfa8b511a6e0e6b0f4b313
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Private Qt module dependencies of a Qt module are recorded
in the IMPORTED_LINK_DEPENDENT_LIBRARIES property of a Qt module.
This property is used to compute the runtime dependency dir path
to be passed to the linker via the -rpath-link option.
If the referenced target does not exist in the scope where it's
used, no -rpath-link will be generated (or at least that specific
dir path won't be passed).
The linking operation will either fail saying the library is not found,
or a different version of the library might be silently picked up in
the sysroot or other implicit lib dir.
Make sure that QtFooModuleDependencies.cmake calls find_package() for
all Qt module private dependencies (or other Qt provided 3rd party
libs in the Qt6:: namespace) so that the targets are in scope and
IMPORTED_LINK_DEPENDENT_LIBRARIES does its job.
qmake also records the INTERFACE_LINK_LIBRARIES of a private Qt module
as the runtime dependencies of the module.
It's not clear why it does that. A private Qt module is an
INTERFACE_LIBRARY so it shouldn't add any new runtime dependencies.
Nevertheless, the find_package part of that has been recently addressed
in 2b6500cd15 for a different reason.
This change is basically the CMake equivalent of
326b91ea78
Pick-to: 6.2
Fixes: QTBUG-86533
Change-Id: Iaf514a14acaded4e8752149cca0c159a271be188
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The constructor from a raw pointer should be
1) constexpr,
2) explicit, and
3) *private*.
We can do 1) without too much trouble.
2) is a (easy to fix) SIC in case of implicit conversions accidentally
relied upon from somewhere.
3) cannot be "easily" fixed by user code (they have to refactor), and
also, it's a BIC on Windows which encodes class members' access in
symbols. Someone may have been exporting some QList subclass, in turn
exporting the iterator classes, and therefore that someone now has the
constructors' symbols with a given access.
So, don't do 2+3 _just yet_ for user code, but set a deadline: Qt 6.5 is
the last that will support this. On Qt 6.6, we switch. All of this on
non-Windows, againt to avoid an ABI break. One can opt-in at any time
via a suitable define.
Given we have this define, use it to guard the other way around as well:
conversions from an iterator to a raw pointer should never be explicit
(there's std::to_address for this).
[ChangeLog][QtCore][QList] Converting a QList's iterator from and to a
raw pointer is deprecated, and will get removed in Qt 6.6. User code can
prepare for the change by defining QT_STRICT_QLIST_ITERATORS.
Change-Id: I0f34bfa3ac055c02af5a3ca159180304660dfc11
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
PRIVATE_MODULE_INTERFACE libraries are linked as interface libraries to
the module's Private target and exported as the dependencies of package
targets. We need to register these modules as public package dependencies
to call find_package when resolving module dependencies in user
projects.
Pick-to: 6.2
Fixes: QTBUG-96558
Change-Id: I4eef550aab306eaf357539ef7a0f76d69873f856
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
file(GENERATE) might fail if an unrelated configuration error happens,
and yet QT_TOOL_COMMAND_WRAPPER_PATH would already be set. Set the
cache variable only if generating was successful and replace the
QT_TOOL_COMMAND_WRAPPER_PATH valiable check with GLOBAL property to
protect the function from double call.
For CMake versions higher than or equal to 3.18 replace 'file(GENERATE'
call with 'file(CONFIGURE' to generate the wrapper at configure time
with the use of a plain semicolon character.
Pick-to: 6.2
Fixes: QTBUG-96870
Change-Id: Icf9c40f571d9c069043604f67ffcf2762966f6d0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
When building Qt we need to set QT_ANDROID_ABIS value to
CMAKE_ANDROID_ARCH_ABI explictily since the automatical detecting of
android ABI is not executed. This fixes build of the qtbase in-tree
tests.
Fixes: QTBUG-97133
Change-Id: Ica7057bcfcc8f4fe4b5a921ca7449f74cdbca0f1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
We don't need to check FEATURE_ltcg, just add -fno-lto unconditionally.
That makes QtCore compile with -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=ON.
Change-Id: Icb2516126f674e7b8bb3fffd16ada2c71d7334aa
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This hasn't worked for some time. It's not in our CI and I don't think
it was working at all. When I tried to build it, I ran into several
problems with C++17 and an Internal Compiler Error I did not have any
interest in working around.
After discussing with the Intel compiler team, it was decided that
fixing those issues in the old compiler is not going to happen. Instead,
their recommendation is to adopt the new LLVM-based compiler, which
the last commit added support for.
This commit does not remove qmake support for the old ICC. It's possible
someone is using qmake with a non-Qt6 project and ICC.
Change-Id: Icb2516126f674e7b8bb3fffd16ad6350ddbd49e5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This includes a few cleanups to our .cmake files where it was easier to
combine existing sections of Clang / AppleClang that no longer needed to
be distinct.
icpx could be replaced with a shell script:
exec `basename $0`/clang++ --intel "$@"
tst_qnumeric is not passing
FAIL! : tst_QNumeric::classifyF() Compared values are not the same
Actual (qFpClassify(tiny / two)): 2
Expected (FP_SUBNORMAL) : 3
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(344)]
FAIL! : tst_QNumeric::classifyD() Compared values are not the same
Actual (qFpClassify(tiny / two)): 2
Expected (FP_SUBNORMAL) : 3
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(344)]
FAIL! : tst_QNumeric::floatDistance(denormal) Compared values are not the same
Actual (qFloatDistance(from, stop)): 0
Expected (expectedDistance) : 4194304
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(408)]
FAIL! : tst_QNumeric::doubleDistance(denormal) Compared values are not the same
Actual (qFloatDistance(from, stop)): 0
Expected (expectedDistance) : 2251799813685248
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(408)]
P
Change-Id: Icb2516126f674e7b8bb3fffd16ad59431e8c3379
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
MoltenVK installed from homebrew has the following
directory structure:
molten-vk/1.1.5/libexec/include/vulkan/vulkan.h
molten-vk/1.1.5/include/MoltenVK/mvk_vulkan.h
Task-number: QTBUG-80576
Pick-to: 6.2
Change-Id: If6f5aeb55908f60fff49417ee1ddf4c2db980c5a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Emscripten complains that this variable is deprecated and should be
replaced with the one given in this patch.
Change-Id: Iafee06fcb1f292de25570545d74d7327679461b0
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
This define used to be set for the entirety of the Qt build but
was lost during the qmake->CMake transition. Re-enable it.
Change-Id: Idc4cb6ada485158559485b60f62f76439550b255
Pick-to: 6.2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This amends commit 165e01d5d5.
Above commit broke the code that adds "${PROJECT_SOURCE_DIR}/cmake" to
CMAKE_MODULE_PATH. The semicolon that separates entries of
CMAKE_MODULE_PATH must be escaped. Otherwise, the semicolon separates
elements of the flags list.
Additionally, fix the QT_AVOID_CUSTOM_PLATFORM_MODULES code path which
lacked the addition of "${PROJECT_SOURCE_DIR}/cmake".
Pick-to: 6.2
Change-Id: I72f78cf066cabe6b0002dce1aa0294aa0dc9cbf0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Do not read the target property LINK_LIBRARIES from interface libraries
as this leads to errors with CMake 3.16.
This amends commit 326b91ea78.
Pick-to: 6.2
Change-Id: I44251c7633d5ecd977cd05746ac311dd1285d1e3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The .pri files for public Qt modules were missing run_depends entries.
Those entries are used by qmake when linking plugins of a static Qt
build. In shared builds, run_depends entries are used to decide whether
to add the -rpath-link argument to the linker. In that matter,
run_depends entries serve a similar purpose as CMake's
IMPORTED_LINK_DEPENDENT_LIBRARIES.
In Qt5, run_depends entries consist of the qmake values QT_PRIVATE and
QT_FOR_PRIVATE.
QT_PRIVATE contains the Qt modules that are privately linked to the
public module, and QT_FOR_PRIVATE are the dependencies of the private
module. That loosely translates to LINK_LIBRARIES of the public module
and INTERFACE_LINK_LIBRARIES of the private module.
Private modules whose public counterparts are already public
dependencies don't have to be added to run_depends.
Pick-to: 6.2
Fixes: QTBUG-84310
Change-Id: If7025c98ea462a2d5a143202df3d98d88e4fee08
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Since commit f3c7d22dd0 we do not use
libraries from /usr/local and other non-system locations on macOS. But
our configure tests still did. This led to discrepancies between
find_package calls in configure tests and the Qt project itself.
Mentioned commit removed /usr/local and friends from
CMAKE_SYSTEM_PREFIX_PATH. But we can't pass this variable to the
configure tests, because CMake sets it up and overwrites our value.
Pass CMAKE_SYSTEM_PREFIX_PATH and CMAKE_SYSTEM_FRAMEWORK_PATH as
QT_CONFIGURE_TEST_CMAKE_SYSTEM_{PREFIX|FRAMEWORK}_PATH variables to
tests.
Tests with separate project files that call find_package() must add code
like this after the project() command:
if(DEFINED QT_CONFIGURE_TEST_CMAKE_SYSTEM_PREFIX_PATH)
set(CMAKE_SYSTEM_PREFIX_PATH
"${QT_CONFIGURE_TEST_CMAKE_SYSTEM_PREFIX_PATH}")
endif()
if(DEFINED QT_CONFIGURE_TEST_CMAKE_SYSTEM_FRAMEWORK_PATH)
set(CMAKE_SYSTEM_FRAMEWORK_PATH
"${QT_CONFIGURE_TEST_CMAKE_SYSTEM_FRAMEWORK_PATH}")
endif()
Adjust pro2cmake accordingly.
Task-number: QTBUG-97076
Change-Id: Iac1622768d1200e6ea63be569eef12b7eada6c76
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When passing an absolute input file name to qlalr, the #line directives
in the output will contain absolute paths. For reproducible builds,
it's desirable to have relative paths.
Pass the input file as relative path to qlalr to produce relative #line
directives.
Fixes: QTBUG-96267
Change-Id: I4ef1e4d5be7cbaf25a54a34ab7c2dbec06411a1d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Certain platform-related variables, in this case UNIX, must be set in a
platform module, because they get cleared after the toolchain file is
loaded. Such platform modules live in upstream CMake, but there is none
yet for INTEGRITY. This manifests in an undefined UNIX variable and
"System is unknown to CMake" warnings for the project and every
configure test.
Add the CMake module "Platform/Integrity" in the cmake/platforms
directory. Add this directory to CMAKE_MODULE_PATH to let CMake load
Platform/Integrity when the toolchain file set CMAKE_SYSTEM_NAME to
"Integrity".
CMake's module directory takes precedence, when loading platform
modules. This is special for platform modules and different from the
documented behavior of CMAKE_MODULE_PATH and include().
In case the user wants to provide their own platform modules via
CMAKE_MODULE_PATH, they can instruct Qt to not add its path by setting
QT_AVOID_CUSTOM_PLATFORM_MODULES to ON.
Make sure that configure tests with project files also load the custom
platform module.
Pick-to: 6.2
Fixes: QTBUG-96998
Change-Id: I9855d620d24dc66353cec5e847a2675b464ace26
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Emscripten only supports
SSE1, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, and 128-bit AVX instruction
sets at this time.
https://emscripten.org/docs/porting/simd.html
Browsers might need to enable simd support in the advanced
configurations
about: config or chrome:flags
Enable by configuring Qt with -sse2
Pick-to: 6.2
Fixes: QTBUG-63924
Change-Id: Ifeafae20e199dee0d19689802ad20fd0bd424ca7
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
