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>
Backstory.
The main reason why we keep getting "unable to promote 3rd party 'X'
target to global scope" errors when building Qt repositories, is
because we try to promote 3rd party imported targets in a different
scope than where the imported targets were created.
What were the main motivations for promoting 3rd party targets to
global?
1) imported targets are by default local to the directory scope they
were created in
2) we want 3rd party targets to be accessible across subdirectory
scopes, but looked up once, e.g. qt_find_package(JPEG) looked up in
src/gui/CMakeLists.txt, but the target should also be usable in the
sibling scope
src/plugins/imageformats/CMakeLists.txt
Having the package lookup close to the consuming qt module is easier
to maintain, because all the other 3rd party dependency lookups are
in the same file. This goes against the conventional CMake advice
where each subdirectory should look for its own dependencies, or the
dependency should be available directly in the root project scope.
3) to make the 3rd party targets available in the root project scope
as part of the following flow:
QtPostProcess.cmake ->
qt_internal_create_module_depends_file() ->
qt_collect_third_party_deps() ->
get_property(INTERFACE_QT_PACKAGE_NAME) ->
write 3rd party Dependencies.cmake file for each qt module.
Properties can only be queried from an imported target if it's in
the same scope or was promoted to global, otherwise you get
'non-existent target' errors.
4) for prl and pri file generation, where we need the targets to be
available during generator expression evaluation within the
relevant qt module directory scope
Here is a list of approaches I came up with on how to improve the
situation.
1) Make all imported targets global during the Qt build, by iterating
over the directory property IMPORTED_TARGETS and making each one
global.
Requires CMake 3.21.
Status: Already implemented for a long time, but is opt-in.
Pros: Relatively robust
Cons: Minimum CMake version for building Qt is 3.16.
2) Make all imported targets global during the Qt build using the
CMAKE_FIND_PACKAGE_TARGETS_GLOBAL variable.
Requires CMake 3.24.
Status: Not implemented, but can be set by Qt builders directly on
the command line.
Pros: Should be robust
Cons: Minimum CMake version for building Qt is 3.16.
3) Abandon the desire to have a single qt_find_package in a single
directory scope, and embrace the CMake-way of repeating the
dependency in each subdirectory that requires it.
Status: Not implemented.
Pros: Should be robust
Cons: A lot of qt_find_package duplication, will require rewriting
various code paths, QtPostProcess would have to be done at
directory scope, unclear if dependency tracking will still work
work reliably when there might be multiple same-named
directory-scoped targets, other unknown unknowns
4) Move all qt_find_package calls into a $repo_name/dependencies.cmake
file which would be read at project root scope. This would
potentially avoid all scoping issues, because all dependencies will
have to be specified at root scope.
Status: Not implemented.
Pros: No duplication
Cons: Dependencies are not scoped anymore to module directories,
won't be able to conditionally look for dependencies based on
module feature evaluation, not clear yet how this will tie into
standalone tests which are in tests/ subdir, other unknown unknowns
5) Try to promote as many 3rd party libraries at project root scope
as possible.
Currently we have 2 general locations where we look up
dependencies.
One is each qt_find_package call. The other is
Qt6FooDependencies.cmake ->
_qt_internal_find_third_party_dependencies().
Many 3rd party targets are created by
_qt_internal_find_third_party_dependencies() in the root scope, but
not promoted, and then we try to promote them in child scopes using
qt_find_package, which causes the promotion errors.
Starting with 58eefbd0b6 and
37a5e001277db9e1392a242171ab2b88cb6c3049 we now record the provided
targets of previous qt_find_package calls.
So instead of waiting to try and promote targets later during the
configuration process, we can make sure we promote the targets at
_qt_internal_find_third_party_dependencies() call time, right
when we lookup the Qt dependencies of the qt repo, in the root
scope.
Status: Implemented in this change
Notably, we only promote 3rd party targets to global for qt builds,
and not user projects, to not accidentally break user project
behaviors.
Also, we only promote 3rd party targets, and not Qt internal
targets like Qt6::Core, Qt6::Platform, Qt6::PlatformCommonInternal,
Qt6::GlobalConfig, etc, for a few reasons:
- the code that requires targets to be global only cares about
3rd party targets
- promoting the internal targets is more prone to breaking, because
there is more than one place where find_package(Qt6Foo) might be
called, and if that ends up being in a different directory scope,
we encounter the same global promotion errors.
Some notable cases where this happens:
- tests/CMakeLists.txt brings in extra Qt packages via
StandaloneTestsConfig.cmake files
- qtbase standalone tests qt_internal_qtbase_pre_project_setup()
calls find_package(Qt6 COMPONENTS BuildInternals) which ends
up creating the Platform target in the root scope instead of
the tests/ scope
- Qt6::BundledLibpng links against Core, which ends up trying to
promote Core's internal dependencies Platform and GlobalConfig
To only promote 3rd party targets, we walk the dependencies of
an initial target recursively, and skip promoting targets that have
the _qt_is_internal_target or
_qt_should_skip_global_promotion_always properties set.
Pros: Improves the situation compared to the status quo
Cons: Still not ideal due to the various filtering of internal
targets and having to mark them as such.
6) Avoid promoting targets to global if we can detect that the target
was created in a different scope than where we are trying to
promote it.
We can do that by comparing the target's BINARY_DIR to the
CMAKE_CURRENT_BINARY_DIR and skip promotion if they are not equal.
Status: Not implemented, but we can consider it because it's
quick to do.
Pros: More robust than newly implemented approach (5)
Cons: Requires CMake 3.18, because trying to read the BINARY_DIR
property on an INTERFACE_LIBRARY would error out.
Also, if we implement it and make it the default when using 3.18+,
we might 'collect' a lot more hidden promotion errors that will
only be revealed later once someone uses CMake 3.16 or 3.17,
because most will probably use newer CMake versions.
Perhaps the trade-off is worth it?
Fixes: QTBUG-89204
Fixes: QTBUG-94356
Fixes: QTBUG-95052
Fixes: QTBUG-98807
Fixes: QTBUG-125371
Change-Id: I088a17a98ef35aa69537a3ad208c61de40def581
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit d2e85cede01c0898ca73cbc3fb9f53aa9612cab5)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
They will used from another Public.cmake file in a follow up commit.
Change-Id: I71b69ed76ca48c391ba45329eb9c305e4a2a238b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit dad49f5a1e91dbdf91a683e0a68d05cdfa2e1ef1)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Will be used in a future commit to do target filtering.
Change-Id: Iaf7039ff456ca11d94c44c6e12f63408d2aaa484
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 4801d4c708f27a1c29118b0dccd24d2e0d3d6ccc)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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.
Change-Id: I260fdbeb95a39f06951dfefc714d3da604abb0bb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit af60bdee8dcb86b73caa23d4d54611b0f1d33bf3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This ensures that the EGL::EGL dependency is promoted to global in
the same scope as GLESv2::GLESv2 if it is a link dependency.
Amends c4d3e5d7d3
Change-Id: Ia156676b40e6d04a5037a305db35192cad306a0c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 52a3ab1eb23915b620948dceb577cf23c1b2391f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It usually looks up the Threads target, so we want it to be recorded
as a provided target.
Amends 58eefbd0b6
Change-Id: I0f06aaae98fd99da8fb6436d232a147e163580a2
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 8c0fb7e07de071de56a74fc637f448afc8bbd102)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
In windows CMAKE_SYSTEM_PROCESSOR can be set to both arm64 and ARM64.
Make the comparison case-insensitive when defining mkspec.
Pick-to: 6.7 6.5
Fixes: QTBUG-127044
Change-Id: Id0c8f04bc0ec6b70993e400f9c285168d4c1499b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 7ae19cee1c782fadfbd0c617568fdad8aba9a493)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Commit ae64c54f8c broke configure
arguments like
--webengine-jumbo-build=20.
That commit transforms the argument to
-webengine-jumbo-build=20
but single-hyphen arguments take values without an equal sign.
We need to store the unaltered argument (with the two hyphens) for
further handling instead of the single-hyphen variant.
Fixes: QTBUG-126872
Change-Id: I243eb072dfe5535a648bd78bb3aeb3b9e0e4ede0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 76d5bceba7f1c553b02def689f2010db671ec60f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It doesn't seem the property was ever used even at the times it was
introduced.
Pick-to: 6.7 6.5
Change-Id: I55d8b558e548908306178827c4149728ce35d0e8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 3bfd1c4ded8cb4a7d1d501401a82e812fc631fc2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Ensure that -D is not prepended to the special sequences like generator
expressions.
Pick-to: 6.7 6.5
Change-Id: I295c289e3d188780d697ff8c62d8c8fc2df6522c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit ff391b5c17309ca8b7bbbaef9028d8b31b847683)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The file was missing from both installation and inclusion.
Pick-to: 6.7 6.5
Change-Id: I3e904071cc28f674750aca38050fbe89d75a585d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 084911a67bde29e49bcb001d593e96fca7836142)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When building user projects replace the FATAL_ERROR about the missing
Qt targets with the WARNING and mention that the linking might be
incomplete. The updated check affected some user projects that used
the linking to the versioned targets and our deferred finalizers. If
Qt targets are not propagated to the global scope or not found in the
top-level directories, finalizers might fail to resolve these targets.
Now users will see the warning. The side effect of the missing targets -
missing plugin linking, or incomplete deployment, both use walk libs
results.
Pick-to: 6.7 6.5
Change-Id: I5c68b548122775424909c62f904f887417816fbc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit b5fa9085146043c9d34025e273b5c9b9918d3db4)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Thiago Macieira
Łukasz Matysiak
Alexandru Croitor
Alexey Edelev
Christian Ehrlicher
Tor Arne Vestbø
Marc Mutz
Oliver Wolff
Piotr Wierciński
Joerg Bornemann