The ccache man page says we have to compile with -fno-pch-timestamp when
using clang and precompiled headers.
"Professional CMake" also recommends this approach, and the ccache
statistics report a marginally better hit rate with this patch.
Task-number: QTBUG-131650
Change-Id: Ic1c17a3977771673ac256674143dbdf8d5ffa28c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Othewise there is a risk that variable is taken from other scopes.
(Random finding).
Pick-to: 6.5 6.8 6.9
Change-Id: I2517adec5d82639e95ac2758633109413811cf9a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QGlobalStatic has a warning suppression for -Wtsan because of its
usage of std::atomic_thread_fence, which TSAN doesn't support.
That header is included in QtCore's PCH, and that triggers a GCC bug
that causes the warning to be emitted despite the suppression [1].
In a developer build, the warning turns fatal.
We could either disable PCHs in such a build configuration
(TSAN+developer-build+GCC < 15), or: simply make the warning non-fatal
on earlier compiler versions.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64117
Pick-to: 6.9 6.8 6.5
Fixes: QTBUG-134415
Change-Id: If80a4acdb1372d00804a60361f6c3d6893b96106
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Compiling qtbase in CYGWIN shows several errors like this one:
In file included from qtbase/include/QtCore/6.9.0/QtCore/private/qcore_unix_p.h:1,
from qtbase/src/corelib/global/qlogging.cpp:61:
qtbase/src/corelib/kernel/qcore_unix_p.h: In function ‘int qt_safe_pipe(int*, int)’:
qtbase/src/corelib/kernel/qcore_unix_p.h:283:14: error: ‘::pipe2’ has not been declared; did you mean ‘pipe’?
233 | return ::pipe2(pipefd, flags); // pipe2 is documented not to return EINTR
| ^~~~~
| pipe
Actually, the error happens because pipe2() is available only when
_GNU_SOURCE is defined:
https://man7.org/linux/man-pages/man2/pipe.2.html
CYGWIN doesn't define this macro by default, so this is reason because
the error happens. In my opinion, the best way for fixing the trouble
is adding the missing _GNU_SOURCE macro by using CMake.
Using qplatformdefs.h, which is also broken for cygwin-g++ target,
doesn't fix the issue, so the only way to solve the problem is to set
it with CMake or forcing it externally by using CPPFLAGS.
Change-Id: I6917630999b29582556258eee11d9989f439c37c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Libc++ is migrating towards fine-grained headers [1], removing indirect
inclusions. To prevent breakages in client code, this feature is opt-in,
happening when one bumps the C++ version used or defines the
_LIBCPP_REMOVE_TRANSITIVE_INCLUDES macro.
This commit adds the macro when building Qt. I'm pretty confident this
won't cause breakages because we have also been building Qt on the CI in
C++ > 17 modes.
[1] https://libcxx.llvm.org/DesignDocs/HeaderRemovalPolicy.html
Change-Id: I7553274ef51ccc9b462c98fdab55b27e5715afaa
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Due to various reasons, Qt WebEngine needs to be built with clang-cl,
while qtbase and other dependencies with MSVC.
clang-cl does not understand all MSVC-style options, which are
recorded and propagated through the PlatformCommonInternal target
which is configured in qtbase using MSVC.
Guard the flags that are not understood by clang-cl with a genex
condition that checks that the compiler is not clang (which implies
clang-cl, because afaik it's not possible to use gcc frontend of clang
against an MSVC-built qtbase).
Pick-to: 6.8
Change-Id: Ibf2c96399a8322ce13814c9c6afa5b57fd8885be
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Zhao Yuhang <2546789017@qq.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Use the _qt_internal_cmake_generator of the PlatformCommonInternal to
store the current CMake generator is used. The property allows checking
the CMake generator as part of transitively propagated properties, like
those we use in PlatformCommonInternal.
Wrap the compile definisions belonging to libcpp_hardening feature
with CMake generator check, since Xcode sets own definitions which
lead to the macro 'redefinition' compilation warning.
Change-Id: I5f6131245746afbe413efc831a9447ba40142a4e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Emscripten supports two exception types:
-fexceptions: Emscripten JS-based exceptions
-fwasm-exceptions: WebAssembly (native) exceptions
These are mutually incompatible and a program should only use
one type. Set exceptions flag based on configure option to
make this happen.
Task-number: QTBUG-129747
Change-Id: I7e80a676aebcfea81f07431df7d50c234b0e3d4d
Reviewed-by: Lorn Potter <lorn.potter@qt.io>
Solaris requires the ssp library to be linked when
-fstack-protector-strong is passed to the compiler.
Pick-to: 6.8
Fixes: QTBUG-129085
Change-Id: I55396fd9dc102ffd98bef54fc3dfc1aadf18a404
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Add the WARNINGS_ARE_ERRORS flags unconditionally, so developers may
control skipping per-target or per-repo.
This allows setting the WARNINGS_ARE_ERRORS cmake option for each repo
independently when configuring them. So qtbase might be built without
the flag enabled and setting the WARNINGS_ARE_ERRORS to TRUE for
the depending repo enables it for the internal Qt targets.
Add the new internal function that controls the related internal flag.
Keep qt_skip_warnings_are_errors for compatibility since it's used
in qtwebengine.
Combine qt_internal_set_skip_warnings_are_errors and
qt_skip_warnings_are_errors_when_repo_unclean functionality in the
new qt_internal_default_warnings_are_errors function.
Change-Id: I1330c75cd67a24e6386f5e94a089e43fa2012bc4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The outcome from the QtCS discussion [0] was that we want to add
std::format support directly into the Qt class' header, so that the
users do not need to include anything extra to be able to use it.
This, however, means that many of Qt headers would include <format>,
which itself is quite heavy. As a result, we decided to add a define
that allows to disable std::format support, if the users do not need
it.
This patch introduces QT_NO_STD_FORMAT_SUPPORT as such definition.
Users can define it in their projects. It is also defined for Qt
for now, because we cannot use std::format inside Qt anyway.
Note that we cannot use compile-time QT_FEATURE for that, because
Qt itself can be configured with different parameters than the user
project.
This patch does not add any public documentation for the definition,
because it's not yet clear where to provide these docs. However, it
adds some comments that would hopefully clarify the situation with
the macros.
[0]: https://wiki.qt.io/QtCS2024_std::format
Fixes: QTBUG-128779
Change-Id: Ie3041966c3a2131e3b47750fbe6831e11b4b74cc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Change-Id: I2b8612f863d674d1420f8643d4200ee3a8076898
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The feature allows enabling/disabling exceptions for the Qt builds.
The feature is disabled by default.
This commit reworks the way the exception flags are set for Qt targets.
Instead of setting them per-target, flags now are set for the
QtPlatformCommonInternal target, which transitively propagates the flag
to other Qt targets. To disable/enable exception flags the newly
introduced property _qt_internal_use_exceptions can be used. The flags
enabling/disabling now can happen any time, but not only at target
creation time. The property has 3 states: TRUE, FALSE, DEFAULT(or
empty). If the property is not set or is set to DEFAULT, the exceptions
feature value is used to set the required exceptions flags. Otherwise
the flags are set according to the property value.
The logic of EXCEPTION argument of the various qt_internal_add_
functions was also updated. If the argument is not provided, the
_qt_internal_use_exceptions property value is set to DEFAULT, which
gives the control on the exception flags to the feature. If the
argument is provided, the exceptions are enabled by setting the
_qt_internal_use_exceptions property to TRUE.
Task-number: QTBUG-118901
Change-Id: I83e3bf52d48a3d16977cce849c9b0765c34f1f21
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The qsnprintf() function introduces even more platform variability
than std::snprintf(), so from now on, we're using only std::snprintf().
Task-number: QTBUG-127110
Pick-to: 6.8
Change-Id: Ic81b2a760521d77442cc328d2cfa7659bba8b7e2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Some Qt internal targets might not work correctly when built with
Intel CET hardening.
Add a per-target opt out to skip adding the Intel CET flags.
Pick-to: 6.8
Task-number: QTBUG-127464
Change-Id: I1a28b228a82b3505d987649eec6db08281c15482
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Introduce some command wrappers for adding the Platform,
PlatformXInternal and GlobalConfig targets, to apply some common
options.
This will allow for less churn in the future when we need to apply
options to all these targets.
The Qt6CoreMacros, Qt6AndroidMacros and Qt6WasmMacros inclusion are
moved before QtBaseGlobalTargets to make the
_qt_internal_add_library command and other platform specific
commands available before we create the Platform targets.
Pick-to: 6.8
Change-Id: I260fdbeb95a39f06951dfefc714d3da604abb0bb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We were doing it only for MinGW, but it's now showing up everywhere.
Pick-to: 6.7 6.8
Change-Id: Ic0adfa808d28487a8303fffd17d9deab60f6cd0a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This change adds a new -sbom configure option to allow generating and
installing an SPDX v2.3 SBOM file when building a qt repo.
The -sbom-dir option can be used to configure the location where
each repo sbom file will be installed.
By default it is installed into
$prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx
which is basically ~/Qt/sbom/qtbase-6.8.0.spdx
The file is installed as part of the default installation rules, but
it can also be installed manually using the "sbom" installation
component, or "sbom_$lower_project_name" in a top-level build. For
example: cmake install . --component sbom_qtbase
CMake 3.19+ is needed to read the qt_attribution.json files for
copyrights, license info, etc. When using an older cmake version,
configuration will error out. It is possible to opt into using an
older cmake version, but the generated sbom will lack all the
attribution file information.
Using an older cmake version is untested and not officially supported.
Implementation notes.
The bulk of the implementation is split into 4 new files:
- QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing
and dispatching the generation of various pieces of the SBOM document
e.g. a SDPX package associated with a target like Core, a SDPX
file entry for each target binary file (per-config shared library,
archive, executable, etc)
- QtPublicSbomGenerationHelpers.cmake - for non-Qt specific
implementation of SPDX generation. This also has some code that was
taken from the cmake-sbom 3rd party project, so it is dual licensed
under the usual Qt build system BSD license, as well as the MIT
license of the 3rd party project
- QtPublicGitHelpers.cmake - for git related features, mainly to embed
queried hashes or tags into version strings, is dual-licensed for
the same reasons as QtPublicSbomGenerationHelpers.cmake
- QtSbomHelpers.cmake - Qt-specific functions that just forward
arguments to the public functions. These are meant to be used in our
Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones
for naming consistency. These function would mostly be used to
annotate 3rd party libraries with sbom info and to add sbom info
for unusual target setups (like the Bootstrap library), because most
of the handling is already done automatically via
qt_internal_add_module/plugin/etc.
The files are put into Public cmake files, with the future hope of
making this available to user projects in some capacity.
The distinction of Qt-specific and non-Qt specific code might blur a
bit, and thus the separation across files might not always be
consistent, but it was best effort.
The main purpose of the code is to collect various information about
targets and their relationships and generate equivalent SPDX info.
Collection is currently done for the following targets: Qt modules,
plugins, apps, tools, system libraries, bundled 3rd party libraries
and partial 3rd party sources compiled directly as part of Qt targets.
Each target has an equivalent SPDX package generated with information
like version, license, copyright, CPE (common vulnerability
identifier), files that belong to the package, and relationships on
other SPDX packages (associated cmake targets), mostly gathered from
direct linking dependencies.
Each package might also contain files, e.g. libQt6Core.so for the Core
target. Each file also has info like license id, copyrights, but also
the list of source files that were used to generate the file and a
sha1 checksum.
SPDX documents can also refer to packages in other SPDX documents, and
those are referred to via external document references. This is the
case when building qtdeclarative and we refer to Core.
For qt provided targets, we have complete information regarding
licenses, and copyrights.
For bundled 3rd party libraries, we should also have most information,
which is usually parsed from the
src/3rdparty/libfoo/qt_attribution.json files.
If there are multiple attribution files, or if the files have multiple
entries, we create a separate SBOM package for each of those entries,
because each might have a separate copyright or version, and an sbom
package can have only one version (although many copyrights).
For system libraries we usually lack the information because we don't
have attribution files for Find scripts. So the info needs to be
manually annotated via arguments to the sbom function calls, or the
FindFoo.cmake scripts expose that information in some form and we
can query it.
There are also corner cases like 3rdparty sources being directly
included in a Qt library, like the m4dc files for Gui, or PCRE2 for
Bootstrap.
Or QtWebEngine libraries (either Qt bundled or Chromium bundled or
system libraries) which get linked in by GN instead of CMake, so there
are no direct targets for them.
The information for these need to be annotated manually as well.
There is also a distinction to be made for static Qt builds (or any
static Qt library in a shared build), where the system libraries found
during the Qt build might not be the same that are linked into the
final user application or library.
The actual generation of the SBOM is done by file(GENERATE)-ing one
.cmake file for each target, file, external ref, etc, which will be
included in a top-level cmake script.
The top-level cmake script will run through each included file, to
append to a "staging" spdx file, which will then be used in a
configure_file() call to replace some final
variables, like embedding a file checksum.
There are install rules to generate a complete SBOM during
installation, and an optional 'sbom' custom target that allows
building an incomplete SBOM during the build step.
The build target is just for convenience and faster development
iteration time. It is incomplete because it is missing the installed
file SHA1 checksums and the document verification code (the sha1 of
all sha1s). We can't compute those during the build before the files
are actually installed.
A complete SBOM can only be achieved at installation time. The install
script will include all the generated helper files, but also set some
additional variables to ensure checksumming happens, and also handle
multi-config installation, among other small things.
For multi-config builds, CMake doesn't offer a way to run code after
all configs are installed, because they might not always be installed,
someone might choose to install just Release.
To handle that, we rely on ninja installing each config sequentially
(because ninja places the install rules into the 'console' pool which
runs one task at a time).
For each installed config we create a config-specific marker file.
Once all marker files are present, whichever config ends up being
installed as the last one, we run the sbom generation once, and then
delete all marker files.
There are a few internal variables that can be set during
configuration to enable various checks (and other features) on the
generated spdx files:
- QT_INTERNAL_SBOM_VERIFY
- QT_INTERNAL_SBOM_AUDIT
- QT_INTERNAL_SBOM_AUDIT_NO_ERROR
- QT_INTERNAL_SBOM_GENERATE_JSON
- QT_INTERNAL_SBOM_SHOW_TABLE
- QT_INTERNAL_SBOM_DEFAULT_CHECKS
These use 3rd party python tools, so they are not enabled by default.
If enabled, they run at installation time after the sbom is installed.
We will hopefully enable them in CI.
Overall, the code is still a bit messy in a few places, due to time
constraints, but can be improved later.
Some possible TODOs for the future:
- Do we need to handle 3rd party libs linked into a Qt static library
in a Qt shared build, where the Qt static lib is not installed, but
linked into a Qt shared library, somehow specially?
We can record a package for it, but we can't
create a spdx file record for it (and associated source
relationships) because we don't install the file, and spdx requires
the file to be installed and checksummed. Perhaps we can consider
adding some free-form text snippet to the package itself?
- Do we want to add parsing of .cpp source files for Copyrights, to
embed them into the packages? This will likely slow down
configuration quite a bit.
- Currently sbom info attached to WrapFoo packages in one repo is
not exported / available in other repos. E.g. If we annotate
WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be
available when looking up WrapZLIB in qtimageformats.
This is because they are IMPORTED libraries, and are not
exported. We might want to record this info in the future.
[ChangeLog][Build System] A new -sbom configure option can be used
to generate and install a SPDX SBOM (Software Bill of Materials) file
for each built Qt repository.
Pick-to: 6.8
Task-number: QTBUG-122899
Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The classic linker (triggered via -ld_classic) doesn't support this flag,
and we can't construct a genex that takes this into account, so add an
opt-out for Qt WebEngine.
Pick-to: 6.7
Change-Id: I62418e0ff37fe8f5bdda2fa8d01b36a8fd44542a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We can't make the choice of whether to enable no_warn_duplicate_libraries
or not based on the Xcode version Qt was built with, as the target flags
will propagate to our cmake integration tests, which we run on platforms
where we don't have Xcode 15.
Pick-to: 6.7
Change-Id: I241a950a3d2e70652a3a6386e5dd86c681d1c13f
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
It seems we ended up passing "_LIBCPP_HARDENING_MODE_EXTENSIVE"
(quoted), not just _LIBCPP_HARDENING_MODE_EXTENSIVE. Remove the
quoting.
Amends 9ff1e6d80bbd5b44b9ec4c0a837d9a4c962698e4
Change-Id: Ia396b0ef638d656a9ea947a378d5623c11e5a544
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This commit enables hardened-specific checks and codegen, inspired by
GCC 14's -fhardened command line switch and LLVM/libc++'s hardened
modes.
We enable (depending on compiler capabilities):
* -ftrivial-auto-var-init=pattern;
* -fstack-protector-strong;
* -fstack-clash-protection;
* -fcf-protection=full or /CETCOMPAT;
* -D_FORTIFY_SOURCE=3 or 2 on Glibc, depending on the Glibc version,
provided that some optimization level is enabled (release build or
optimized debug build);
* on libstdc++, -D_GLIBCXX_ASSERTIONS;
* on libc++, -D_LIBCPP_HARDENING_MODE set to
_LIBCPP_HARDENING_MODE_EXTENSIVE in debug and to
_LIBCPP_HARDENING_MODE_FAST in release (_DEBUG is too slow);
* -Wl,-z,relro,-z,now.
This aligns us 100% with -fhardened (we already pass -fPIE and -pie
anyhow). Some Linux distributions already ship GCC/Clang with some of
these options enabled by default.
The check for Intel CET has been amended to always test if the compiler
supports the corresponding flag; and, if so, enable the feature. Before,
it was behind a configure option and the test only checked if the
compiler had CET support automatically active (the test didn't pass
-fcf-protection to the compiler).
The check for -fstack-protector-strong has been made general (rather
than QNX-specific). We don't support QNX < 7 anyhow.
Finally, the qt_config_linker_supports_flag_test test has been
amended to also support MSVC.
All of the hardening options are enabled by default.
[ChangeLog][Build System] Qt builds by default in "hardened mode",
meaning that a series of security-related compiler options are
automatically enabled. In the unlikely case in which these options
constitute an unacceptable performance hit, it is possible to disable
individual hardening options when configuring Qt.
Change-Id: I2c026b0438010ad10d5e7b1136fedf4ae3af8822
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Give it a name in line with the function name:
qAsConst -> QT_NO_QASCONST, as already done for qExchange.
We can do this because we never documented the macro itself.
So, while at it: also document the macro.
Change-Id: I6eb0834df438e4f4e818ef2cf8e702ed156dc253
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
A bug in Xcode 15 adds duplicate flags to the linker. In addition, the
`-warn_duplicate_libraries` is now enabled by default which may result
in several 'duplicate libraries warning', and build failure if
`-Wl,-fatal_warnings` is passed. By adding the newly introduced
flag, `-no_warn_duplicate_libraries`, to the linker we can suppress the
warnings, and possible fatal error caused by this bug.
Change-Id: I65e06ea039a6e98b02ed1f9112c622ecc6a142b5
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
clang-cl share many parameters with MSVC, but it makes the CMake code
complex. We temporarily remove the clang-cl compat code paths from the
MSVC code and they will be brought back in a central place in a separate patch.
Change-Id: I28b93c04d65e9a5133d61c7fbbdc5c83cc8cc37e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Features enable code coverage collecting using the gcov tool. The
resulting reports can then be post-processed by lcov or similar tools.
[ChangeLog][CMake][Coverage] Added the coverage configuration argument.
The only supported coverage tool at the moment is gcov. The argument
requires Qt is built in Debug otherwise setting the argument leads to
the configuration error. Typical usage:
<...>/configure -developer-build -coverage gcov
Task-number: QTBUG-86223
Change-Id: I39b2061f544997a7c4fe6f4d135c0ab447f15a17
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The density of Q_FOREACH uses in this and some other modules is still
extremely high, too high for anyone to tackle in a short amount of
time. Even if they're not concentrated in just a few TUs, we need to
make progress on a global QT_NO_FOREACH default, so grab the nettle
and stick to our strategy:
Mark the whole of Qt with QT_NO_FOREACH, to prevent new uses from
creeping in, and whitelist the affected TUs by #undef'ing
QT_NO_FOREACH locally, at the top of each file. For TUs that are part
of a larger executable, this requires these files to be compiled
separately, so add them to NO_PCH_SOURCES (which implies
NO_UNITY_BUILD_SOURCES, too).
In tst_qglobal.cpp and tst_qcollections.cpp change the comment on the
#undef QT_NO_FOREACH to indicate that these actually test the macro.
Task-number: QTBUG-115839
Change-Id: Iecc444eb7d43d7e4d037f6e155abe0e14a00a5d6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Currently QT_USE_QSTRINGBUILDER is added for all Qt module targets by
default, and it's not possible to remove this definition.
Replace this definition with the generator expression that is
propagated by the PlatformModuleInternal target.
Change-Id: I1c606e16809dc720e2eb72191e1670dfc48f1b48
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Currently QT_USE_QSTRINGBUILDER is added for all Qt tool targets by
default, and it's not possible to remove this definition.
Replace this definition with the generator expression that is
propagated by the PlatformToolInternal target.
Change-Id: Iac3bd3ea76e7b439cf7957146b4b6dd20ecdbe3a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMP0099 changes the way of LINK_ONLY genex works. With CMP0099 set to
OLD LINK_ONLY genex only links the exact library binary/archive without
propagating other interface options from the target. This feature was
exploited by PlatformXInternal targets to avoid propagating of their
linker options. Nowadays when CMP0099 is forced to NEW by Qt scripts,
including user-facing, we cannot rely on LINK_ONLY genex.
Introduce _qt_is_internal_target property that is set for all Qt
executables and explicitly limits the propagation of the linker
options from PlatformXInternal targets.
Pick-to: 6.5 6.6
Fixes: QTBUG-113641
Change-Id: I3a0ecddb65886e435073feb24c1b47035130ba70
Reviewed-by: Alexandru Croitor (OOO) <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Fix the argument prefix that is used in the cmake_parse_arguments call.
Pick-to: 6.5 6.6
Change-Id: Ie02bdf7d2769ce084b0d173c1e8152ca6fc4fe53
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
By not explicitly disabling min/max macros of `windows.h`, we may see
some unintended substitutions. This is especially important now that we
are moving toward enabling Unity Build, and some of the constructs for
manually dealing with this issue, eg., `#ifdef max`, `#undef max`, might
not make it to the pool, and as a result we get build failure.
Pick-to: 6.5
Change-Id: Ie3c31aebe00300126a2ac3a6044876ab92d5d99c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Xcode 14's Clang will emit objc_msgSend stubs by default, which ld from
earlier Xcode versions will fail to understand. Disable these stubs
explicitly for static libs, for as long as we support Xcode < 14.
See https://github.com/llvm/llvm-project/issues/56034
Pick-to: 6.5
Fixes: QTBUG-112820
Change-Id: Id762873d61b9d147bf3eb6292297e7b80b7393e1
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Besides `stringop-overflow`, the `stringop-overread` is also buggy, and
it has some false positives. If not silenced, this will break the
unity build as several warnings are being emitted in qmetaobject.cpp,
etc.
Pick-to: 6.5
Change-Id: I708c81057c01d8d8fc9694c394c89602a2f6867b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
All current modules are free of qAsConst, make sure new ones will be,
too.
Change-Id: Iae3c67bca86eddf62ae664b00ff39a9b513d7290
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We've ported all qExchange() to std::exchange by now, across all
modules, but the one in QScopedValueRollback was left behind, because
it requires C++20's version of std::exchange (constexpr).
Since q20::exchange was not approved, replace the qExchange() here
with two moves and add a comment to port to std::exchange() once we
can depend on C++20.
Then add QT_NO_QEXCHANGE to avoid new uses from creeping in.
Change-Id: I488e252433e78fb2766639dbe77a22a55196cfd1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This is a level A SIC, as it breaks
QFile f = "/some/path";
In general, it's not a good idea to have this implicit conversion. A
QFile is not a representation of a path, so the conversion should be
explicit.
I am going to keep the current semantics (implicit conversion) up to and
including Qt 6.8 (LTS). Starting from 6.9, the constructor will be
unconditionally explicit. This is deliberate, and done in order to make
users fix their code while staying in Qt 6, rather than encountering
this issue (and countless many more) if and when they upgrade from Qt 6
to Qt 7. In the meanwhile, users can opt-in to the new semantics by
defining a macro.
[ChangeLog][QtCore][QFile] The QFile constructors that take a path are
going to become unconditionally `explicit` in Qt 6.9. Code like `QFile f
= "/path";` will need to be ported to equivalent one (e.g. `QFile
f{"/path/"}`). This has been done in order to prevent a category of
mistakes when passing strings or paths to functions that actually take a
QFile. Users can opt-in to this change even before Qt 6.9 by defining
the QT_EXPLICIT_QFILE_CONSTRUCTION_FROM_PATH macro before including any
Qt header.
Change-Id: I065a09b9ce5d24c352664df0d48776545f6a0d8e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The default Windows SDK installed for VC++ 2022 is 10.0.19041, and still
has the issue described here, breaking builds if -Zcpreprocessor is set:
https://developercommunity.visualstudio.com/t/stdc17-generates-warning-compiling-windowsh/1249671
The issue might be fixed in SDK version 2104 (10.0.20348.0), but until
that is the default SDK when installing the compiler, turn that
conformance check off again.
Partially reverts commit 8cb832090a8a0e7226904561f97c6de954d752ed
Change-Id: Ib22f8d196b978274ce31be727826b902e79aaa99
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
/Zc:lambda seems buggy. Although in my experiments it works well
for 99% Qt repos, it seems some tests will trigger the bug and it
also blocks some new commits. So disable it for now, it's not stable
enough.
Now that this check is disabled, the workaround for tst_qstringapisymmetry
is also not needed anymore, so remove the workaround as well.
Partially reverts commit 8cb832090a8a0e7226904561f97c6de954d752ed
Change-Id: Icf0ecbbaa6262522470e5f5dea05705985ab18f1
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
For the full list, please refer to [1].
Needed to change the qstringapisymmetry unit test:
In theory we don't need the array to be static and it did compile
without any problems so far, indeed. However, with this patch applied,
MSVC complains that the lambda function below can't access the array.
I don't understand why, because we use [&] in the lambda and it should
capture all the variables in theory, but in reality it failed to
capture this variable in the end. And making the variable static
solves this issue. Maybe it's a MSVC bug.
Already tested locally. Most Qt repos build without any issues,
only very few repos are not tested, as my local environment
can't build them.
[1] https://docs.microsoft.com/en-us/cpp/build/reference/zc-conformance?view=msvc-170
Change-Id: I658427aa171ee1ae26610d0c68640b2f50789f15
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Previously we did not create Qt6:: namespaced aliases.
This is needed as a workaround preparation for getting the package name
of a module target from one of it's properties.
Before it would fail in qtinterfaceframework because
ifvehiclefunctions-simulation-server uses PUBLIC_LIBRARIES
in its qt_internal_add_app call, and because _add_app does not handle
such an option, some weirdness in qtbase's _add_app -> _add_executable
-> _extend_executable -> _register_target_dependencies ended up trying
to register PlatformAppInternal as package dependency.
That issue will be handled in separate changes.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Ifd03528c95b08cb6837a6aaa26cbf97c0cbabbb4
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
To enable CET for MSVC, only passing "/CETCOMPAT" to
the linker should be sufficient.
Enabling generation of EH Continuation (EHCONT) metadata
is additional protection and should not be necessary.
It also requires all the dependencies to be re-compiled
with EHCONT enabled, otherwise the linker will refuse
to link the obj files. However, this is rather hard
to achieve if your application depends on many 3rd-party
libraries, so to let people enable CET more freely,
we don't enable EHCONT guard by default.
Pick-to: 6.4
Change-Id: Iba08a5ec56c474d291991fb751a0de764719bd85
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's deprecated as of Xcode 14, and generates a warning message if a
project explicitly enables bitcode. The App Store no longer accepts
bitcode submissions from Xcode 14.
Pick-to: 6.2 6.3 6.4 5.15
Change-Id: Ib1f9d5114ca4d8b1845ecc7a9de0473ee015db33
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
