Solaris requires the ssp library to be linked when
-fstack-protector-strong is passed to the compiler.
Fixes: QTBUG-129085
Change-Id: I55396fd9dc102ffd98bef54fc3dfc1aadf18a404
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 73875b8bb5faf9f6ec1064704efaae76e33b0e35)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Even though we set foo_ROOT in the provisioning scripts and CMake is
picking it up as the base dir, we should also use it as CMake variable
so we can look in other directories below foo_ROOT.
Change-Id: I193d8ff1c216a669162569d71891c3eb7b9b030f
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit c68277c41b99d6791e3c1a5998b70c6cbbf6dc15)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
If a user accidentally passes 'CMAKE_OSX_ARCHITECTURES=x86_64;arm64'
to configure on a Linux x86_64 platform, the build would fail when
compiling qdrawhelper_avx2.cpp.o either due to an architecture
mismatch, or due to not recognizing the -Xarch flag on older gcc
compilers.
Only add xarch flags to SIMD compilation on Apple platforms.
Change-Id: I322316979626b04cb0378f4dbf3cc26ec96183ac
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
(cherry picked from commit 3f3d8604e6ed5b6854301f4a3c4799cfa256d8b0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We cannot use the fancy options in PlatformGraphics since user projects
lack of their evaluation in QtPlatformSupport.cmake. Use the explicit
CMAKE_SYSTEM_NAME-based conditions instead. Those should work if
respective CMAKE_SYSTEM_NAME is specified in the toolchain file.
Amends 3322f585eb5ad11acc1f93ecaafb42e30e37b197
Change-Id: Ifb6ced360e8cade7315b2b238837578bfc9a1bc3
Reviewed-by: Kimmo Ollila <kimmo.ollila@qt.io>
Reviewed-by: Karim Pinter <karim.pinter@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 43cac6eaa90897e50daf6105b19528b82bf776aa)
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add the unified PlatformGraphics module, which looks for either Integrity
or VxWorks platform graphics.
The PlatformGraphics module creates the interface
PlatformGraphics::PlatformGraphics target which links the respective
platform graphics target. It's expected that from the platform graphics
targets to deliver the consistent subset of definitions, libraries,
include directories, compiler and linker flags and also the special
<platform>_REQUIRED_<LIBRARIES|INCLUDES|DEFINITIONS> variables.
The <platform>_REQUIRED_<LIBRARIES|INCLUDES|DEFINITIONS> variables are
consumed by the PlatformGraphics::PlatformGraphics and stored in the
respective _qt_internal_platform_graphics_required_<type> property, to
access the value without scope limitations. The property then is
checked by the EGL and GLESv2 modules(this can be done elsewhere too)
and is appended to the CMAKE_REQUIRED_<type> variable before running
the respective compiler checks.
Task-number: QTBUG-128455
Change-Id: Id1987c6294327509a14fbeeb7b8bf39aad6f486c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Karim Pinter <karim.pinter@qt.io>
(cherry picked from commit 3322f585eb5ad11acc1f93ecaafb42e30e37b197)
The QT_DECLARE_Q{,E}SDP_SPECIALIZATION_DTOR_WITH_EXPORT macros make the
destrcutor of the particular instantiations be out-of-line and exported
from the library in question. In many cases, the class name that is
being instantiated can found in a _p.h and this causes syncqt to mark
any use of this class as private API, including this constructor that is
meant to be used from inline (user) code.
This patch marks all such instantiations to be "public" API. That will
include some uses that shouldn't be so marked, but this is easier than
having to do it piecemeal.
The ELF version was changed for thsee Symbols changed in QtGui (for example):
QExplicitlySharedDataPointer<QPlatformPixmap>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QColorSpacePrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QPageRangesPrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QColorTransformPrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QPdfOutputIntentPrivate>::~QExplicitlySharedDataPointer()@@Qt_6
QExplicitlySharedDataPointer<QEventPointPrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QPageRangesPrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QColorTransformPrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QPenPrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QFontVariableAxisPrivate>::~QExplicitlySharedDataPointer()@@Qt_6
QExplicitlySharedDataPointer<QPlatformPixmap>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QColorSpacePrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QEventPointPrivate>::~QExplicitlySharedDataPointer()
QExplicitlySharedDataPointer<QPenPrivate>::~QExplicitlySharedDataPointer()
Task-number: QTBUG-128656
Task-number: QTBUG-117514
Change-Id: I1f25f1e61bb98159f9d3fffd63acbe04098cfef6
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 33707235841981133edfdfcd88cc6e234aa4fc45)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Our general strategy is to support the latest two iOS releases,
as most people upgrade their iOS devices quite aggressively.
But given that iOS 18 is not out yet, and that people still
spend some time upgrading once it's out, we don't want to be
in a situation where we effectively only support iOS 17.
Fixes: QTBUG-128678
Change-Id: I959794944807e5b6b5e56f22d3c57977bc4f2aee
Reviewed-by: Doris Verria <doris.verria@qt.io>
(cherry picked from commit e2c4a1669e5b6496d52e2f55a94bd7d4f4469b98)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Some vendored 3rd party sources or libraries may not have a CPE
because the upstream disappeared, we don't know where the files
originally originated from, or no CPE was ever issued.
Given that the 3rd party files are shipped with Qt, they can
be considered as part of the "Qt" CPE for vulnerability tracking
reasons.
In such cases, we should add the Qt-specific CPE to the SBOM to ensure
that the SBOM is as complete as possible when tooling analyzes the
third party packages.
Task-number: QTBUG-122899
Change-Id: I32a70e24742a860198f3a6b12bdb4a06057f1ab3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 3cadd4b1f62479cce88c99cd8c95729ac10a6126)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Instead specifying Interbase_INCLUDE_DIR and Interbase_LIBRARY allow to
use Interbase_ROOT instead. Use this new option in the sql driver
documentation.
Additionally add 'fbclient_ms' as possible library name so we don't need
to distinguish between Interbase and Firebird anymore.
Change-Id: I472f95f82ebb93888002deccdf5028a1827a4745
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 89dd15e359228a57351bddc2429db4d57863bc8f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
c661dbd42d injected `QT_NO_INT128` into
every TU when compiling for VxWorks.
VxWorks uses a custom stdlib implementation that does not support 128bit ints
and at the same time they use an off the shelf Clang that defines
`__SIZEOF_INT128__` which is used to detect if 128b ints are available.
This resulted in Qt falsely assuming that 128b ints are available.
Detect if 128bit are available instead of injecting `QT_NO_INT128` and
define `QT_COMPILER_SUPPORTS_INT128`, use it instead of directly
checking `__SIZEOF_INT128__`.
Task-number: QTBUG-115777
Change-Id: I7531ebe780b4bdd78b42daf8dae0e522a316a88e
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit 5a10744bb4afc0c95b1b7bbba8848cf14b0bad00)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Qt attribution json files might want to specify more than one PURL or
CPE for a given entry. Change the build system code to detect whether
a JSON PURL or CPE key contains an array of values, and if so, convert
it to a cmake list and use that for further SBOM handling.
As a result, the PURL_QT_VALUE, PURL_3RDPARTY_UPSTREAM_VALUE, and
PURL_MIRROR_VALUE getting an 'S' at the end, aka they are renamed to
PURL_QT_VALUES, PURL_3RDPARTY_UPSTREAM_VALUES, and PURL_MIRROR_VALUES.
Also the attribution key is now called just PURL instead of
UpstreamPURL.
The CPE json attribution key and option name stay the same.
Amends 47fd38be4bce0958fcfce8080d1580c4e3c2a15b
Amends 95b7fe49900904d19fca21876c84f97c2a6ae03d
Amends f7e1123620b623be0c321b54eaba7a1d618a7ce1
Task-number: QTBUG-122899
Change-Id: Ieec919901c3b44df80bc196536f68632a9761d92
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 797ce76ee946245898f9d11fa7e3ffb889e117d7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The dependency is specified for the Ninja generator, but is missing for
others, which leads to the invalid order when building with Unix Makefiles
generator for MacOS platform.
Amends 103eca1070
Pick-to: 6.7 6.5
Fixes: QTBUG-127987
Change-Id: I78927ee3fa7b0926f03b0e5eab67983c4d0d3e67
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 2d87bb7d2eb9827899546cca3e59e8174ce04b8c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Instead specifying Oracle_INCLUDE_DIR/ORACLE_LIBRARY use Oracle_ROOT
which is suits much better for the usecase.
Change-Id: I8a0858b3ae491212a79ad982eb8e067e6f1b750f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
(cherry picked from commit 5e478ebbcc42471b4c70c10bb513e7343c05933e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Instead specifying CMAKE_INCLUDE_PATH/CMAKE_LIBRARY_PATH use
MySQL_ROOT which is suits much better for the usecase.
Change-Id: Ieb75f80a6eb3a3e7913a7c04ca6511a014fa7e4e
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 0c0b5cbb0d0b43f6be4e54caea89d5764511e94f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Implicitly detect macOS cross-compilation in case the value of
CMAKE_OSX_ARCHITECTURES is a single arch that is different from
the real host macOS architecture.
In that case, the build system will implicitly set both
-DCMAKE_SYSTEM_NAME=Darwin and -DCMAKE_CROSSCOMPILING=TRUE.
It will also set those variables in the qt generated toolchain file,
otherwise user projects might not be built with the correct
architecture depending on the arch of the host machine where the user
project is built.
For such a cross-compilation scenario, as usual, a host Qt needs to be
specified during configuration, for usage of its host tools. Which
means that if cross-compiling to x86_64 from arm64, we will not try
to build and use the x86_64 tools via Rosetta.
Fixes: QTBUG-121322
Change-Id: Ib484af445b3fc6eb676b0ee174ac81d63f2f450f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit fc2fa92de02e8b57472058a8281c24775e97d9eb)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
A developer can cross-compile Qt and force the build of the tools
for the target architecture. In this case, the resulting Qt libraries
and tools can theoretically be used as an SDK on the target platform
without having to rely on host tools or packages.
Examples of this scenario include Boot2Qt, cross-building a Qt SDK for
a raspberry pi on a more powerful machine, or cross-building an arm64
macOS SDK on an x86_64 machine.
To achieve that, the build system needs a way of disabling the
mandatory host path check and the lookup of the Qt6HostInfo package
that are added due to the nature of 'usual' cross-compilation cases.
This was partially addressed in
0f8017efb6 by offering an opt out via
the QT_REQUIRE_HOST_PATH_CHECK and QT_NO_REQUIRE_HOST_PATH_CHECK
variables.
The change was incomplete though. While it was possible to disable
the _qt_internal_setup_qt_host_path call at user project time, it was
not possible to disable the lookup of the required Qt6HostInfo
package in _qt_internal_find_host_info_package.
Change the code to consider the value of QT_REQUIRE_HOST_PATH_CHECK
also when looking up the Qt6HostInfo package in Qt6Dependencies.cmake
in user projects.
When building additional Qt repos, as opposed to user projects,
where we call _qt_internal_find_host_info_package in
qt_internal_setup_find_host_info_package via the BuildInternals
package, users will still need to pass both QT_REQUIRE_HOST_PATH_CHECK
and QT_NO_REQUIRE_HOST_PATH_CHECK to disable the host path check.
This case is less likely to happen, so no adjustment is made to unify
that behavior.
Additionally make it also possible to use an environment variable
as an opt-out with the same QT_REQUIRE_HOST_PATH_CHECK name.
Amends 0f8017efb6
Change-Id: I3b1f35d1540493680323330bddc28c65e88b966f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 98450a332e317aeafa3381abd6266829e8900758)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This complements commit 30e04340dac26ebd09f9bc8ceb598e873ab63ba7
("Switch to non-strict C++ builds so QT_SUPPORTS_INT128 is true") and
adds the same modification to tools and apps.
Otherwise qtconnectivity's sdspscanner won't compile, as it needs
quint128.
Task-number: QTBUG-119901
Change-Id: Ib9a6fe573e9420a471fdfffd76a2e43d3c5496d8
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 7e37962cd0d1faf65249e08020619ef7175a280e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
As documented in our platform support docs.
Change-Id: Iadcf369facbe5d798827c486e564a6e124f2836c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 1bd70d671247a9b0e709fda2a077a9dbf46c276f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Instead, the package name should be determined by the sub-attribution
target name. Otherwise the build system will try to generate multiple
files with the same name, but different content.
Amends 5daabb5a74c4e7c5d087da7f9207d79d2ee05b13
Task-number: QTBUG-122899
Change-Id: I10b4ec2fe8f38d70d13918dc980d1bd1d9145cb6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit d624592ca40e05033432de72e0c4d9f6570b5544)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
A project's root qt_attribution.json file might be picked up by the
build system when recording system libraries for SBOM processing.
One such case is qtgrpc.
This caused generation errors in qtgrpc with the following message:
CMake Error: Files to be generated by multiple different commands:
qt_sbom/SPDXRef-Package-qtgrpc-qt-3rdparty-sources-WrapProtobuf.cmake
This started happening since the SBOM options are now implicitly
propagated to auto-created attribution targets, and each attribution
target attempted to generate to the same partial sbom file.
Any qt attribution file in the project root is not intended to be
used for system libraries, so explicitly disable using the
root attribution file for all system libraries.
As a more long-term fix, we should consider making the partial sbom
files be more unique.
Amends 5daabb5a74c4e7c5d087da7f9207d79d2ee05b13
Task-number: QTBUG-122899
Change-Id: I67544c299e630597f26602d270cd1dfd54cccfb6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 55b399fdcd12bdfc645d4ec7d25b3c881d11a09a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Also split up the CPE handling to allow for more values to be set,
rather than preferring the first one that is encountered.
Task-number: QTBUG-122899
Change-Id: I3209cb5d66f5483c7294b40816431d9df75e00e5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 47fd38be4bce0958fcfce8080d1580c4e3c2a15b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Using a single PURL for a target is not enough to represent all the
information that an SBOM processing tool might want to know about.
For example for the bundled harfbuzz package, we want to inform at
least about two versions: the upstream version that was originally
imported into Qt sources, and the Qt version or sha1 of the sources
that were used, because the 3rdparty code might have been modified and
there might be new Qt-specific vulnerabilities.
To handle this, we need to generate multiple PURLs for a single
target.
Introduce six new options to be understood by qt_internal_add_module
and other SBOM functions:
- PURL_QT_ARGS
- PURL_MIRROR_ARGS
- PURL_3RDPARTY_UPSTREAM_ARGS
- PURL_QT_VALUE
- PURL_3RDPARTY_UPSTREAM_VALUE
- PURL_MIRROR_VALUE
The first three options take multiple arguments, and will generate a
PURL for each used variant, based on the purl parsing options that
were previously handled. For example passing:
PURL_3RDPARTY_UPSTREAM_ARGS
PURL_TYPE "github"
PURL_NAMESPACE "harfbuzz"
PURL_NAME "harfbuzz"
PURL_VERSION "v8.5.0" # tag
will generate a PURL pointing to the upstream harfbuzz repo hosted
on github.
The next three options allow specifying a purl value directly as a
single string, rather than as separate parts. This might be useful
when the PURL is pre-constructed and read from a qt_attribution file.
Example:
PURL_3RDPARTY_UPSTREAM_VALUE "pkg:github/harfbuzz/harfbuzz@v8.5.0"
When no arguments are specified, targets like Qt modules or Qt
3rd party libraries will have automatically generated QT and MIRROR
variant PURLs that point to code.qt.io and github.com, along with
important info like the version and subdir source path for a given
target.
Third party libraries are expected to be manually annotated with a
3RDPARTY_UPSTREAM variant PURL that points to the original upstream.
In a future change, these will be read from a qt_attribution.json
file.
The final set of generated PURLs for the harfbuzz package might look
like:
pkg:github/harfbuzz/harfbuzz@v8.5.0
pkg:github/qt/qtbase@5018b71e99f?library_name=BundledHarfbuzz#src/3rdparty/harfbuzz-ng
pkg:generic/TheQtCompany/qtbase-BundledHarfbuzz@5018b71e99f?vcs_url=https://code.qt.io/qt/qtbase.git@5018b71e99f&library_name=BundledHarfbuzz#src/3rdparty/harfbuzz-ng
Additionally a few more purl parsing options are added.
Add a PURL_USE_PACKAGE_VERSION option that will use the
qt_attribution.json or custom PACKAGE_VERSION value as the PURL
version, so it doesn't have to be manually specified.
This is an opt-in, and not the default, because some attribution
files contain plain text, white-space separated, strings as the
version value (like the 'sha3' 3rd party lib) which ends up generating
a broken PURL and a failing JSON conversion of the SBOM.
So we have to manually annotate targets that should use the
attribution json package version, until a better way to handle this
can be found.
Add a PURL_VCS_URL option that will generate a PURL qualifier (a HTTP
query parameter) with the given value, to indicate to SBOM-processing
tools what is the upstream repo URL for the package.
They can use this information to display known vulnerabilities for the
package hosted at that URL.
This is mostly useful for the generic QT purl variant, and is
automatically generated for Qt entity types.
Task-number: QTBUG-122899
Change-Id: Ie000b01b478bef4bff6f4803dd39e37b7a8055d5
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit f7e1123620b623be0c321b54eaba7a1d618a7ce1)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
They should inherit the version of the 3rd party library they are part
of, and not be treated as Qt modules.
Task-number: QTBUG-122899
Change-Id: Ibf99f4481fbc1acca488fc96cca048298b080d35
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit b17dfbbb992b1d38d7a1aeb2b0109bab9cb1e4e3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Previously if an option like CPE was passed to a 3rd party target that
would create nested attribution targets, one per entry in the
attribution file, the CPE option would only apply to the first /
parent target, but not to the nested targets.
This change will now propagate all SBOM options to the nested targets,
but only if the parent target is not a Qt entity type like a module,
plugin, etc, which means it will only apply to 3rd party attribution
targets. The restriction is there because because mostly only 3rd
party attribution targets should inherit the same set of CPEs and
similar SBOM values.
If the restriction proves to be too strict, it will be re-assessed in
a future change.
Task-number: QTBUG-122899
Change-Id: I96cfa046ad611c10877b7a06504b35615b539bbe
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 5daabb5a74c4e7c5d087da7f9207d79d2ee05b13)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
A previous commit disabled QT_SUPPORTS_INT128 if the Standard Library
doesn't properly specialize <type_traits> and <limits> for the 128-bit
types, like libstdc++ in strict mode. As a consequence, we now need to
compile Qt in non-strict mode so QT_SUPPORTS_INT128 is true when
building Qt, at least if the compiler supports 128-bit integers in
principle.
Statically assert that QT_SUPPORTS_INT128 is defined if the compiler
in principle supports it, to catch other problematic platforms early.
We have a few out-of-line implementations that should be built if the
compiler supports int128 in principle, so that Qt users are free to
use the types if their compiler supports them and not run into missing
support in the Qt library. This patch ensures this.
Compiling in non-strict mode removes the early warning we were getting
from it, but a) headersclean still uses strict mode, so at least our
headers are regularly checked and b) this is a cross-platform project;
if we were to use platform-specific extensions unprotected, other
platform's compilers will still complain.
Fixes: QTBUG-119901
Change-Id: I974f95ca0f26085dd0fe5ceb8bbef4f62467979a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 30e04340dac26ebd09f9bc8ceb598e873ab63ba7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Previously one had to specify names like 'QtSvg' to -skip-tests
and -skip-examples, but this is not the same behavior as what
the -submodules and -skip options expect.
To keep it consistent, change the code to consider only the lower case
names.
Amends 25b89f2c88
Amends 7c9efdf40c
Pick-to: 6.7
Fixes: QTBUG-127857
Change-Id: Ie80edb98ce16b6835fe361198953e36b8255102a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 34f127834c2d83517687522b5725f6a67f67bad2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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
Change-Id: Ic81b2a760521d77442cc328d2cfa7659bba8b7e2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit b8a956c2d3f9c158594265eca89185bd2bc671e7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When QT_INTERNAL_EXAMPLES_INSTALL_PREFIX is set, the build system
should ignore the DESTDIR env var when installing examples. Otherwise
the examples will still be installed into a location where the Coin
agent will archive the files, and thus blow up the package size,
especially if each example contains deployed Qt libraries.
Backup and temporarily unset the DESTDIR env var while example
installation is in progress.
Amends 02cb165ef8050230b477358e4136e9f0acd83eb6
Amends 7694b01aaf
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: Ibe24a88dd672d246b579d815a813dd042f60e6a6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 90db9a41566f0fdb26b7a80b68b55ac0360489f0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The Qt6 package needs to be found before calling
qt_build_internals_set_up_private_api, otherwise it will fail when
using a cross-compiled Qt, because QT_HOST_PATH will not be set.
The error is:
CMake Error at qtbase/cmake/QtBuildHelpers.cmake:341 (message):
You need to set QT_HOST_PATH to cross compile Qt.
Call Stack (most recent call first):
cmake/QtBuildHelpers.cmake:444 (qt_internal_check_host_path_set_for_cross_compiling)
cmake/QtBuild.cmake:4 (qt_internal_setup_build_and_global_variables)
cmake/QtSetup.cmake:6 (include)
cmake/QtBuildRepoHelpers.cmake:21 (include)
lib/cmake/Qt6BuildInternals/QtStandaloneTestTemplateProject/Main.cmake:7 (qt_build_internals_set_up_private_api)
cmake/QtBuildRepoHelpers.cmake:1036 (include)
cmake/QtBuildRepoHelpers.cmake:1053 (qt_internal_setup_standalone_test_when_called_as_a_find_package_component)
lib/cmake/Qt6BuildInternals/Qt6BuildInternalsConfig.cmake:68 (qt_internal_setup_build_internals)
CMakeLists.txt:11 (find_package)
Pick-to: 6.7 6.5
Fixes: QTBUG-127668
Change-Id: I2fb3df05ce7aed3949d428d98657fe61de723abd
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 4f9da08b058382cf170bf3a0e14fc73c8cf4fecd)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Add code to generate and install a source SBOM SPDX file for every
repo. It relies on the python 'reuse' tool being installed and
available in PATH.
Also add code to allow running 'reuse lint', which checks compliance
with the reuse specification.
The features are only enabled when configuring with
-DQT_GENERATE_SBOM=ON
-DQT_GENERATE_SOURCE_SBOM=ON
-DQT_LINT_SOURCE_SBOM=ON
which will be the case for our CI in a follow up patch.
Because most of our repos are not yet reuse compliant, the actual
generation of the source SBOM and the linting is skipped if the
project root directory does not contain a REUSE.toml file.
This allows incremental handling of each repository, while also
enforcing the compliance at installation time when the REUSE.toml file
is actually there.
The source SBOM generation and linting will run at installation time,
but they can also be manually triggered at build time using the
ninja 'sbom' and 'reuse_lint' custom targets.
Various opt outs are provided as a fail safe:
- QT_FORCE_SOURCE_SBOM_GENERATION to force source sbom generation
even if a REUSE.toml file is not present in the root source dir
- QT_FORCE_REUSE_LINT_ERROR to force linting to error out, even if
a REUSE.toml file is not present
- QT_FORCE_SKIP_REUSE_LINT_ON_INSTALL to skip linting at installation
time, but allow running it at build time
These can be set either locally or conditionally passed to CMake
inside repo-specific Coin instructions.
Task-number: QTBUG-122899
Task-number: QTBUG-125211
Change-Id: I664e69830936c4427688143ee86b98782c1733ab
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 6d9b4291746907e30ea49ac0adf8608ad8a1129b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Some operations might want to install additional files next to the
repo sbom, with the same file base name as the repo sbom file name.
E.g install qtbase.source.spdx.json next to qtbase.spdx.json.
Make the output file path without the extension available in a new
QT_SBOM_OUTPUT_PATH_WITHOUT_EXT variable during installation.
Task-number: QTBUG-122899
Change-Id: I0b9442cffa3f3b0fd2387e77569a94e43ce387a5
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 35bd5df58932299221ad475ebaf25e2c0492e6a0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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.
Task-number: QTBUG-127464
Change-Id: I1a28b228a82b3505d987649eec6db08281c15482
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
(cherry picked from commit c5e42a9d2faef611e3a6d124d5b093670346fb87)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Tools that consume SBOMs expect that each SBOM package will contain a
unique purl: https://github.com/package-url/purl-spec
Each Qt target maps to an SBOM package, so generate a target-specific
PURL for each Qt target, by using the combination of the repo name
and target name as the purl name.
The purl external reference will then look something like:
ExternalRef: PACKAGE-MANAGER purl pkg:/TheQtCompany/qtbase-Gui@6.8.0
Also allow customizing the purl for each target by specifying one of
the following options to functions like qt_internal_add_module or
qt_internal_extend_sbom:
- PURL_TYPE
- PURL_NAMESPACE
- PURL_NAME
- PURL_VERSION
- PURL_SUBPATH
- PURL_QUALIFIERS
- NO_PURL
- NO_DEFAULT_QT_PURL
Task-number: QTBUG-122899
Change-Id: I6926dd773a0ef6fc688664bcac7b23483ecbabe6
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit f6fdc1fe5fde253d7e70a2d2bbef42e9c411956e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
For some targets, it might not be possible to specify all 3rd party
dependencies information for SBOM generation.
qtwebengine is one of these cases, where the 3rd party targets are
only known to GN, and not CMake.
Add a new SBOM_INCOMPLETE_3RD_PARTY_DEPENDENCIES option which can be
passed to qt_internal_add_module and friends.
This will include an informational message into the SBOM package
comment field that the dependency information might be incomplete.
Also add an SBOM_PACKAGE_COMMENT option, which can be used to provide
further information if necessary.
Task-number: QTBUG-122899
Change-Id: I5e893e1e205aae4a5591a457be88d5db54fa8fc3
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
(cherry picked from commit 04ade5acc923ae04142004551ce8c7560517d192)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We never added the qmake subdirectory if we didn't build tools. Thus
we never created a doc target to build qmake's documentation.
Make sure we add the qmake subdirectory regardless of whether we build
tools or not. qt_internal_add_tool can then make sure to skip building
the tool if necessary.
If the tool is not created though, create a fake qmake INTERFACE
library target, so that qt_internal_add_docs has a target to work
with.
Amends 5c352f47b9
Fixes: QTBUG-127334
Change-Id: I41cc96fb6ad21e32e17d312ea474835dfa38528e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit aea0f89cfa4aca7e4c7b5056c425fb44ce394770)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It triggers vulnerabilities when loading the SBOM into tools that look
for CVEs matching those CPEs.
Task-number: QTBUG-122899
Change-Id: Ic4949ca5749ce4e297344760d3500d982c9a4449
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
(cherry picked from commit ad0ed9fe307ac01ceb3fadd32816ada961a5afa6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This reverts commit 361d0b7222fd35133186571762640aada67fa39b.
The qmake behavior is fixed by b66ecb295ecc3981b1c21f01d62c9066f5d6e6ca
so that the original fix can be reinstantiated.
Change-Id: I5338e4cbebc963f48469e7492f18375e56a46200
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 39c36d3230ea26ff327bb1d727c1fd049932fb93)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
CMake by default generates an Xcode project with an overridden
CONFIGURATION_BUILD_DIR Xcode attribute pointing to an absolute path
build dir.
Due to a bug in Xcode, that causes dSYMs not to be included in an
xcarchive after invoking the Xcode archiving task.
This can be worked around by re-setting the CONFIGURATION_BUILD_DIR
attribute to have the value "$(inherited)". That ensures that Xcode
places the dSYMs into an expected location, that can then be included
in an xcarchive.
Unfortunately overriding CONFIGURATION_BUILD_DIR breaks certain CMake
build path preconditions, which can result in broken behavior like
$<TARGET_FILE:app> genex evaluation not working, as well as ignoring
of the CMAKE_RUNTIME_OUTPUT_DIRECTORY property.
So modifying the CONFIGURATION_BUILD_DIR can only be done as an
opt-in, where the project developer knows the risks and can decide if
it will affect the project.
The project can opt into the risky fix by setting the
QT_USE_RISKY_DSYM_ARCHIVING_WORKAROUND cmake variable to ON before
creating any targets using qt_add_executable.
If Xcode fixes this bug in the future, we can make the variable a
no-op when we detect a new enough Xcode version.
Pick-to: 6.7
Task-number: QTBUG-126866
Change-Id: I37e8dee569fc45654f149219b8933769ed237fda
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit ff1ba4f1c9da383b357745c2261de5b0050cdf3c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
CMake by default uses the Release configuration for the Xcode archiving
task, providing no way to choose a different configuration. CMake also
sets the "generate debugging symbols" Xcode option aka the -g flag to
NO for the Release config, because it is not the RelWithDebInfo
config. This means that by default the archived project will never have
debugging symbols.
Change the GCC_GENERATE_DEBUGGING_SYMBOLS Xcode attribute to YES for
all the release configs (Release, MinSizeRel, RelWithDebInfo), as well
as the debug config. This matches the defaults of a project created
in Xcode directly and ensures debug symbols are generated for all
configs.
Another issue is that the Xcode project generated by CMake shows no
values for the debugging format option, which is controlled by the
DEBUG_INFORMATION_FORMAT attribute. In contrast a project created in
Xcode directly, sets the Debug config format to "dwarf" and the
Release config format to "dwarf-with-dsym".
This prevents inclusion of the dSYMs into the archive, because the
dSYM would not be created in the first place.
Override the DEBUG_INFORMATION_FORMAT per-config. The release configs
get the 'dwarf-with-dsym' variant, while the debug config will have
'dwarf'.
This matches the values of a new project created directly in Xcode.
Each of these assignments can be opted out by setting one of the
following variables:
- QT_NO_SET_XCODE_DEBUG_INFORMATION_FORMAT
- QT_NO_SET_XCODE_GCC_GENERATE_DEBUGGING_SYMBOLS
These changes improve the defaults for a CMake generated Xcode
project, but are not sufficient to ensure that dSYMs are included into
the archive created by the Xcode archiving task.
For that, the project also needs to set the CONFIGURATION_BUILD_DIR
attribute to '$(inherited)' to avoid a bug in Xcode, where it can't
copy dSYMs out of a non-inherited build dir into the archive.
Qt can't do that unconditionally, because it violates CMake's build
path preconditions, resulting in things like $<TARGET_FILE:app> genex
evaluation not working, as well as ignoring of the
CMAKE_RUNTIME_OUTPUT_DIRECTORY property.
A follow up change will provide an opt-in to do that, but only at the
project developer's own risk.
[ChangeLog][CMake] CMake-generated Xcode projects will now include
debugging symbols by default, regardless of configuration type, and
Release-like configurations will default to using dSYM bundles instead
of keeping the debug symbols in object files, to match Xcode project
defaults.
Pick-to: 6.7
Task-number: QTBUG-126866
Change-Id: Ie17b40e53ba22658a098f9a162c7bcfb1711c45b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 7ccf30ae46272ace13bedc33ccf5f116ff57091b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
There was a typo in the original change, which caused none of the qml
plugins in a prefix per-repo build being picked up.
Amends 06fef6219e
Pick-to: 6.7
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: Ibf14d9e0cbb0302c69d32071f4ba090f24a5798d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 1ab33d575a6993ceb8d9482c20d5c7d6deb252ea)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This reverts commit 7ae19cee1c782fadfbd0c617568fdad8aba9a493.
Reason for revert: breaks non-cross QMake builds on
Windows on ARM64. The QMake mkspec is now reported as
win32-arm64-msvc, and apparently, QMake is not prepared for this.
Change-Id: I45c19719c6f0862580dbff09244337283305ee6c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 361d0b7222fd35133186571762640aada67fa39b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Usually apps created by qt_internal_add_app() are not meant for
installation on Android, and are excluded from installation using
qt_exclude_tool_directories_from_default_target().
Some repos might be missing the exclusion call, which means the app
would be built and installed on Android.
qt_internal_add_app creates MODULE_LIBRARYs instead of EXECUTABLEs
when targeting Android. While the SBOM machinery only expects
EXECUTABLEs for apps.
If the app target is not excluded (in which case the SBOM would be
skipped), this would cause the SBOM code to error out saying the
target type is unsupported.
To prevent further errors like this, add MODULE_LIBRARY as a valid
target type for qt apps.
Task-number: QTBUG-122899
Change-Id: I3ec80add22f0584638990171c59b78c24725c052
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit d24936dbdc85d5fe875b5d3df702630df4d4ba9d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
qt_find_package is only meant to be used for looking up 3rd party
packages. Using it with Qt packages can cause issues where we record
the Qt packages as 3rd party packages.
When using a developer build, issue a warning when qt_find_package is
called with a provided target that starts with the Qt6:: namespace.
Change-Id: Ic2a2d613dbf4fa7e7c51e9b73696bf14e4af866f
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 2339cb3ea282d4ad31fd74fd2a127a986a29a3cf)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Joerg Bornemann
Christian Ehrlicher
Alexandru Croitor
Alexey Edelev
Thiago Macieira
Tor Arne Vestbø
Łukasz Matysiak
Marc Mutz
Oliver Wolff
Piotr Wierciński