When Qt is configured using the configure script, rather than directly
via CMake, we can obtain the full list of configure arguments passed
from the config.opt file.
Add the configure line to the repo project SBOM package comment field
when it is available.
Task-number: QTBUG-122899
Change-Id: I0c5554dcda2f71ec4ba034b14c82a99757dc790c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit b6ee361bc7540db36c334fea0b9d355fbed9a2a2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Previously SBOM generation was opt-in.
This patch changes the generation of the plain-text tag:value SBOM
to be enabled by default, except for:
- developer builds
- no-prefix builds
- standalone tests or examples
- cmake build tests
The JSON SBOM generation and the verification steps have also been
changed to be enabled by default, but only if the Python dependencies
can be found. If the dependencies are not found, the build will
skip the generation and verification steps.
Four new configure options have been added to control these aspects:
-(no-)sbom-json: Allows explicitly enabling or disabling JSON SBOM
generation
-(no-)sbom-json-required: Fails the build if JSON SBOM generation
Python dependencies are not found
-(no-)sbom-verify: Allows explicitly enabling or disabling SBOM
verification
-(no-)sbom-verify-required: Fails the build if SBOM verification
Python dependencies are not found
There are corresponding CMake variables for each of the configure
options, see the cmake mapping document.
[ChangeLog][Build Systems] SBOM generation is now enabled by default,
when building Qt, except for developer builds and no-prefix builds.
JSON SBOM generation is enabled by default if the required Python
dependencies are available.
Task-number: QTBUG-122899
Change-Id: I6dbe1869f8342154a89ff2ab84ac53c9ef1b2eb7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 96c5e55c111d957bd7b5294d2c2eb1d919cce871)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This will allow us to run only the first, but not the second, if the
second won't have it's dependencies met.
Task-number: QTBUG-122899
Change-Id: I141b4bd3b76a71495c760a118bdf1397ee7e16b5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit f15b3c864ee47177d4f13cf7a047f245c11c4d00)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Introduce a bunch of helper functions to split out the finding of a
specific python interpreter, a specific python dependency within a
given python interpreter, and the handling of dependencies for each of
the possible SBOM operations: GENERATE_JSON, VERIFY_SBOM, and
RUN_NTIA.
In a future change this will allow us to conditionally enable certain
operations, depending on which dependencies are available, without
failing the build outright.
One behavior change is better logging of what goes wrong if a
dependency is missing.
Another is the double look up of python on macOS, to account for the
system framework python not having the required dependencies.
These was previously an internal opt in, but now it is done
automatically.
Task-number: QTBUG-122899
Change-Id: I3054f2649c0092dc5f2d3e299065f0f62dc6c5fb
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 29a435faf84fbe9a80a3054c2dcce4d691b46e20)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The DESTDIR env var needs to be evaluated at install time, not
configure time, so the $ENV{} needs to be escaped in the generated
script.
Also improve the error message a bit, to say which path exactly it
expected to read.
This fixes SBOM generation for the debian package builds.
Task-number: QTBUG-122899
Change-Id: I6869f0054601dcb35ae7ad7b55f808df4dc12311
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 08d5d9e9da8a4815be7dd2c952cb45a6597cc077)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Otherwise the spdx id recording function might fail when trying to
retrieve the spdx id from the non-existent target.
Task-number: QTBUG-122899
Change-Id: I1f6b3d7bc88ff4aa28de1468cd86152747cc3bdb
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 4e120f265cc5d96399b01402ed53568abecde3d0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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).
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>
(cherry picked from commit 515ad07a12c4bf190545ae38eff588f7b979d68e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The macro sets the Qt related PATHs and attempts to call
execute_proccess command in resulting environment. This command should
be used to reproduce the _qt_internal_generate_tool_command_wrapper
behavior for execute_process. Since we may control the environment
during the CMake execution, there is no need to use a proxy batch
script to configure it.
The use of tool command wrapper in execute_process has a potential
issue related to the invalid command line processing. cmd.exe is
unable to parse command line correctly if the first argument is batch
script containing spaces and the follow arguments contain spaces as
well. execute_process internals use API that has exact same behavior.
Task-number: QTBUG-128420
Pick-to: 6.7 6.5
Change-Id: I2339c85ed611da89176629878db550b7b7976367
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit b68b3e773c68b577c55db76ca5c211e919ae8136)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Can be useful for non-Makefile and Ninja generators, even if they
are unsupported for building Qt.
Change-Id: I02a622c89f725c3ae5b51ea345a530eaa5529976
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 08d1d113f140b1b4be5a387696a8a35934905d64)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Otherwise the SBOM is not regenerated if the attribution files are
modified.
Task-number: QTBUG-122899
Change-Id: I5b3f62e254aa70021ed06fac73f881bcbb110c31
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit e579b2884e68292e535bc773502f68ad083860cb)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
After 4dce218ac400afcb54aa2a85a0b27947fec583cb got merged, we started
considering the INTERFACE_LINK_LIBRARIES property of UNKNOWN_LIBRARY
targets in addition to INTERFACE_LIBRARY targets, when collecting
dependencies for pri file generation.
These can contain genexes like $<LINK_ONLY:...> or
$<TARGET_OBJECTS:...>, which are not supported by file(GENERATE),
or special directory scope tokens like ::@, which are not valid
targets or library names.
One such case was in the downstream vcpkg build of Qt which adds
`$<LINK_ONLY:EXPAT::EXPAT>` to the INTERFACE_LINK_LIBRARIES of the
Fontconfig::Fontconfig target.
We strip or handle these cases for prl file generation as part of
calling __qt_internal_walk_libs.
Change the pri generation to handle them in a similar manner by copying
over the same logic.
Amends 4dce218ac400afcb54aa2a85a0b27947fec583cb
Fixes: QTBUG-129471
Change-Id: Id4a574ee2411f6d64179c419f352168fde1914d3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 93df3de1f30b6f65b025b33e9cd73ad479295e59)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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>
Alexandru Croitor
Alexey Edelev
Joerg Bornemann
Christian Ehrlicher
Thiago Macieira
Tor Arne Vestbø
Łukasz Matysiak
Marc Mutz