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>
WrapBrotli::WrapBrotliDec depends on WrapBrotli::WrapBrotliCommon.
OpenSSL::Crypto depends on ws2_32 and crypt32 on Windows.
These dependencies are currently missing in generated pri files, because
WrapBrotli::WrapBrotliDec and WrapBrotli::WrapBrotliDec are
UNKNOWN_LIBRARY. Currently only INTERFACE_LIBRARY's
INTERFACE_LINK_LIBRARIES are processed when generating pri files.
Pick-to: 6.7
Change-Id: I45a7ecbbb843adbe3aea7fdc68cec6c794015552
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 4dce218ac400afcb54aa2a85a0b27947fec583cb)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
qt_find_package() sets QT_TARGETS_OF_QMAKE_LIB_<NAME> to all provided
targets, without checking if each target exists.
qt_generate_qmake_libraries_pri_content() iterates targets listed in
QT_TARGETS_OF_QMAKE_LIB_<NAME>. If a target does not exist,
qt_generate_qmake_libraries_pri_content() trusts it as a library name
and adds it into QMAKE_LIB_<NAME>_<CONFIG> directly.
3073b9c4de adds zstd::libzstd_shared to
the PROVIDED_TARGETS argument of qt_find_package().
When WrapZSTD::WrapZSTD is found but zstd::libzstd_shared doesn't exist,
QMAKE_LIBS_ZSTD now contains wrong content "libzstd::libzstd_shared".
Pick-to: 6.7
Change-Id: Id2a79d6c028a80e53d7b9a6a6d11f436d40dde65
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 56853235458799bbf993fa7f2fa19ecf9bbdae9c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
FFmpeg records its library dir in INTERFACE_LINK_DIRECTORIES, its
INTERFACE_LINK_LIBRARIES are library names without directories.
Currently FFmpeg's linker flags in pri and prl files is broken,
such as "-llibavcodec.a" in QMAKE_PRL_LIBS (should be "-lavcodec"),
and "libavformat.a ws2_32" in QMAKE_LIBS_FFMPEG (should be
"-lavformat -lws2_32").
Fix this by enabling qt_get_library_name_without_prefix_and_suffix()
and qt_get_library_with_link_flag() to handle args like "libavformat.a"
and "ws2_32", to produce correct -l flags.
Also avoid adding duplicate "-L" flags in pri and prl files, since all
FFmpeg libraries are installed in the same location.
(Amends 2c49f85380 and
2915921ad2)
On a Mingw static build with static FFmpeg, and FFmpeg libraries isn't
installed in compiler's implicit link directories. Before this change:
// mkspecs/modules/qt_lib_multimedia_private.pri
QMAKE_LIBS_FFMPEG = libswscale.a libswscale.a libswresample.a
libswresample.a libavutil.a bcrypt libavutil.a libavformat.a ws2_32
secur32 libavformat.a libavcodec.a ole32 strmiids ole32 mfuuid
libavcodec.a
// plugins/multimedia/ffmpegmediaplugin.prl
QMAKE_PRL_LIBS = ... -llibavformat.a -lmfuuid -lstrmiids -lole32
-llibavcodec.a -llibswresample.a -llibswscale.a -lbcrypt -llibavutil.a
After this change:
// mkspecs/modules/qt_lib_multimedia_private.pri
QMAKE_LIBS_FFMPEG = -lswscale -lswscale -lswresample -lswresample
-lavutil -lbcrypt -lavutil -lavformat -lws2_32 -lsecur32 -lavformat
-lavcodec -lole32 -lstrmiids -lole32 -lmfuuid -lavcodec
// plugins/multimedia/ffmpegmediaplugin.prl
QMAKE_PRL_LIBS = ... -lavformat -lmfuuid -lstrmiids -lole32 -lavcodec
-lswresample -lswscale -lbcrypt -lavutil
Fixes: QTBUG-126773
Pick-to: 6.7
Change-Id: I71a06c960a4f9b6010fc2847cc08833d58b74e1c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit e154da485e83d2867da391088ea4acb31eef6293)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The value of QT_I18N_TRANSLATED_LANGUAGES is reflected in generated
Info.plist files. We should do the same for QT_I18N_SOURCE_LANGUAGE.
Pick-to: 6.7
Fixes: QTBUG-126790
Change-Id: Id9d680a183047942585e00f5d8cf1ac3c2352c9f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit ea435bb12766fea1a20cfdf67b8433593d20aeae)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
As part of fee1518294 we enabled framework
debug builds, which left us with an inconsistent library naming. The
framework libraries are always unsuffixed, e.g. QtGui.framework/QtGui,
while we were adding _debug suffixes to the plugins and static libs.
This was confusing macdeployqt, as it uses simple string matching logic
for "_debug_" to detect that a Qt build is a debug build, and since
the framework library didn't have a suffix it then failed to deploy
the suffixed plugins.
We now follow the requirement from the framework naming and skip the
suffixing for all libraries in this configuration.
Change-Id: I982253fc46c65aa3fab52f8658f62ef63cdac49f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit d3be87ff1d558f05309b1f29f7e71f291498584f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When creating non-aliased versionless targets, make sure we also add
the config-specific IMPORTED_LINK_DEPENDENT_LIBRARIES properties, so
that for older CMake versions, we still get the -rpath-link handling
of the dependent libraries.
Amends 173164cd47
Task-number: QTBUG-126727
Change-Id: I22618a51bd98cc851ec1a01a27086e0b878bee8d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 16f49f6a1c58919fb15c82d8381d7fc0ff5557ad)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When a shared library target has private dependencies to another
shared library, they are exported by CMake into the target's
IMPORTED_LINK_DEPENDENT_LIBRARIES_<CONFIG> property.
This property then is read by the consuming project to determine which
file paths need to be added to the -rpath-link linker option.
Due to the simple logic that CMake uses to process this property,
if the project CMAKE_BUILD_TYPE does not match the _<CONFIG> part of
the property, the dependent libraries will not be added to
-rpath-link, causing link failures.
Make sure we explicitly set all the possible variants of the property
in our custom Qt6FooAdditionalTargetInfo.cmake file, to ensure we
always pick up the relevant dependent libraries for processing.
In conjunction with 173164cd47 and
1c287cea29 in qtbase, this should
hopefully avoid most -rpath-linking issues for QNX and Yocto builds.
Task-number: QTBUG-126727
Change-Id: I16a9cb5553d57e5ea3edc28cc2aab89c77f02a75
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 9fe100e270cb5b60fe5d1100c0b5074226873213)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We need to pass all dirs where sboms will be generated, for external
document referencing.
We also need to set up dependencies between the repo sbom custom
targets, so that qtsvg sbom is only run after qtbase sbom.
We use the dependencies.yaml info to set up the dependencies.
Task-number: QTBUG-122899
Change-Id: Id3331e11742bc2c86e7ed52ce26b3ff21eace359
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 31126b2b775ae52a0d74aadf1aff8f6d79d0c6be)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Repositories like qtwebengine and qtinterfaceframework might search
for a Python interpreter earlier than _qt_internal_sbom_find_python is
called and might find an older version of Python that is not
sufficient for SBOM purposes.
In that case Python3_EXECUTABLE would have been set, we would not try
to look for Python 3.9 and then fail trying to find python
dependencies or when executing one of the SBOM steps.
Rework the lookup process to be contained in a function rather than a
macro, make sure we temporarily reset any found python executable so
far and explicitly look for Python 3.9 after which we cache it into
custom cache var.
This allows finding and using a Python interpreter for SBOM purposes,
without interference from a possibly older version already found for a
different purpose.
Because the macro is now a function, we can get rid of some of the
backup state management code.
Task-number: QTBUG-122899
Change-Id: Ia846843a4e5cc8c91963ea76557639fc19e25913
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit e7bfdb976a2478c0d6d33cffa40b475ca106a28f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
If a target has the _qt_internal_excluded_from_default_target property
set, don't try to add file SBOM information for the target, because
the file will not be built nor installed by default.
We check for a new custom _qt_internal_excluded_from_default_target
property instead of EXCLUDE_FROM_ALL, because EXCLUDE_FROM_ALL might
be set to a genex that excludes all configs except the main one, but
we are interested whether the target is entirely excluded.
Task-number: QTBUG-122899
Change-Id: I79d6a4b0c65356da14f7ff50ee3639705f5fabbd
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 34b5dc041b0d34a76c081719fafa8f48265e34ae)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We need it to disable generation for certain repos like qtqa, even
if the platform config says that SBOMs should be enabled.
We can't just set QT_GENERATE_SBOM to OFF, because the general SBOM
CI instructions are added later that module specific ones, and thus
would override the value back to ON.
Providing a separate internal variable allows us to disable it with a
higher priority.
Task-number: QTBUG-122899
Change-Id: If7803ae4aac0886d605a542e3f05ad9533bb8108
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 0ea3164969bbc7eda71bcf77e716e2a8ec23c8c4)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Un-alias system target names before processing them for the SBOM,
otherwise we'll get errors about trying to set properties on alias
targets.
Amends 37a5e001277db9e1392a242171ab2b88cb6c3049
Task-number: QTBUG-122899
Change-Id: Ifef2108be123549505ed67f0b9c258a10431c84e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 089111aee0d4a98900aa35fa24d1a9cbbb03b905)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
In certain cases the qt_find_package(PROVIDED_TARGETS) might not
exist, so we shouldn't record the targets for SBOM spdx id
registration in that case.
Amends 37a5e001277db9e1392a242171ab2b88cb6c3049
Task-number: QTBUG-122899
Change-Id: Iada6b5a20a3e7526f18ae4385db8a29fee68ab36
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 0f5699ee3ddb2ec426f1b9c51484ec96241db8bf)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
In diff of below change, patch set 4 to 5, the list(APPEND) was
replaced with a string(APPEND), but the escaping of semicolons was not
removed. This caused an issue with packages that provide multiple
targets when configuring qtsvg in a static qt build.
Remove the unnecessary escaping.
Amends 58eefbd0b6
Change-Id: I1755f31b333e7cf76722cff490349bcc159d7e93
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 9279a2f60e15ae02eb74f12db74a83cf3c1848d4)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We want to avoid using the NEW behavior of CMP0156, since the linking
order we specify matters in several cases, even if this lead to
library duplication in linker command line. Until the NEW policy
behavior with the Qt code is not fully tested we should force the
policy to OLD, and keep the existing behavior.
Pick-to: 6.7 6.5
Change-Id: I61641f499e71a14d90b4d92419a6b916029dbc0b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 9702c3c78b2c16db6a9d0515d7d7698d9b064cd8)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Previously when configuring on the first run,
when qt_configure_process_path was called with the default "./plugins"
for INSTALL_PLUGINS, we would write that value directly to
qconfig.cpp.
After a build, if we reconfigured qtbase, the function would then
canonicalize the path via file(RELATIVE_PATH), and write 'plugins' to
qconfig.cpp, which would cause unnecessary rebuilds.
Make sure we canonicalize the path on the first configuration as well,
to avoid the rebuilds.
Simplify the code a bit, and fix a drive-by where we set rel_path to
"." before, but never actually set the cache variable in that case.
Amends 48dbcefe57
Amends c269d8f086
Change-Id: I8749a85946e93cdf8672113638b499d0d3a31e5c
Pick-to: 6.7
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 0856387f5a6b3b928400045054b60cfd896ee06b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We were doing it only for MinGW, but it's now showing up everywhere.
Pick-to: 6.7
Change-Id: Ic0adfa808d28487a8303fffd17d9deab60f6cd0a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit ae71a00c611ce07965d6a4e54e7a5aee3105da5e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
If the VerifySBOM feature is enabled, pass additional options to
CMake configuration:
- runs syntactic verification of the SBOM
- so it converts the generated SBOM files into JSON files (and
installs them). This does additional useful validations.
- runs the NTIA SBOM verifier
- shows some of the content in the SBOM in a more user-friendly table
format via the sbom2doc python app
- runs sbomaudit to show things like packages without a license
expression, doesn't exit with errors if issues are found.
To ensure the tables are wide enough in the log on the CI, we set
an explicit value for COLUMNS env var, which is used by sbom2doc
to determine the table size.
To ensure the sbom2doc and sbomaudit python applications are found,
we supply additional locations where they can be found, via the
env vars that coin python provisioning sets.
We also make sure to pass the found application paths when executing
the python apps, because they might not be in PATH by default.
Task-number: QTBUG-122899
Change-Id: I0baef8b9c949209b15ab304e1e840b4dcdf5a61c
Reviewed-by: Toni Saario <toni.saario@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 83ff34d1c626759224a95f39bca8337a8390ed52)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Avoid duplication and move finalizer code to a new
function "_qt_internal_finalize_wasm_app", which can
be called from the add_executable functions.
Change-Id: I4859a3999725ebf61a496d78665b6a259dfeb0f5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
(cherry picked from commit 2116c62256bbf1bc3d516430509a93177572d86f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This prevents setting it more than once, which will
on recent Emscripten versions cause 'duplicate symbol'
linker errors.
Change-Id: Ie6c2ede0569271cf3a02fc993b14bbf27f69ff57
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
(cherry picked from commit 320cb68ce5c0c718c6434adfefa6c7460e3cb08a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This linker option is now deprecated (and not needed,
since stack traces always contain demangled symbols).
Change-Id: If42c692c006b214fa3df418c09680aaa07ea2bbd
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
(cherry picked from commit a8b7da59cba56b535393f50cd7432a412021d8d2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Add a NO_ATTRIBUTION_LICENSE_ID option to allow to skip including
license references from qt_attribution.json files.
Add a QT_LICENSE_ID option that can take an "id" value and return one
of the common license expressions we use throughout Qt repositories:
- GPL3 with exception for tools / apps
- GFDL for documentation
- GPL3 only modules
etc.
Add a QT_SBOM_DEFAULT_QT_LICENSE_ID_LIBRARIES variable that can be set
at directory scope (or root repo scope) to use a specific license id
for all qt modules / plugins created within that repo, e.g. the
Commercial + GPL3 variant. These can be opted out, to fallback to the
"default" license by passing NO_DEFAULT_QT_LICENSE_ID_LIBRARIES.
Add a similar variable QT_SBOM_DEFAULT_QT_LICENSE_ID_EXECUTABLES
for tools / apps, including a NO_DEFAULT_QT_LICENSE_ID_EXECUTABLES
option.
Modify the logic for setting licenses for qt targets:
- use whatever is set in QT_SBOM_DEFAULT_QT_LICENSE_EXECUTABLES
for tools and apps
- or use the 'GPL3 with exception' variant for tools and apps
- use whatever is set in QT_SBOM_DEFAULT_QT_LICENSE_LIBARRIES for
modules ands plugins
- or use the default Commercial + LGPL3 + GPL variant for
modules and plugins
Amends 37a5e001277db9e1392a242171ab2b88cb6c3049
Task-number: QTBUG-122899
Change-Id: I3a8abac62b9f4b342f91ef139064884f02aa935e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit fe90ba704168d47cf88d0c6512380b525f38f5d3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Previously, only a very short subset of options related to attribution
files could be specified to qt_internal_add_module /
qt_internal_extend_target.
It is more convenient to allow specifying most (safe) options, instead
of calling another function.
Unsafe are considered paths like INSTALL_PATH and derivatives, TYPE
which is too generic, and some other ones like LIBRARIES which would
be duplicated, and causes warnings in cmake_parse_arguments if
duplicated.
Change the code to allow specifying most SBOM options and forwarding
them to _qt_internal_extend_sbom.
Task-number: QTBUG-122899
Change-Id: I6eb723e165edf59973d83c66eace43acdce237de
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 81162cc8b6931c8659dc722be97eb788e344812a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Alexandru Croitor
Oliver Wolff
Alexey Edelev
Piotr Wierciński
Joerg Bornemann
Li Xinwei
Tor Arne Vestbø
Thiago Macieira
Morten Sørvig