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>
The value should be taken from the QT_SBOM_LICENSE_EXPRESSION
variable. The '_qt_internal_sbom_get_default_qt_license_id' was a copy
paste error.
Amends 37a5e001277db9e1392a242171ab2b88cb6c3049
Task-number: QTBUG-122899
Change-Id: I4bcfaaf06af8903af7081130ba3c8285a53d8f4f
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 8f04225c5af2a5cb31d2452342b4ec35a10bf77b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We were comparing the variable name of single and multi arg options,
rather than the value.
This accidentally worked when the variables were set, but forwarding
empty values if the variables were not set.
Explicitly evaluate the variable values to compare them against the
empty string.
Amends 96abceb64e5dc0570ca7c3419f401cfafe946ba0
Change-Id: I1a701c681f5af5e665601972687024ce734aa014
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 6f475a05a1a035b07ed66f93aa92d0e8b2396047)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This avoids a "must set EXPORT_NAME when using MODULARIZE
with pthreads" error when linking libQtGui.so.
Both settings only apply for the final executable since
they affect how the wasm module is loaded from JS;
setting them together here makes sense.
Change-Id: Ibebeeee38203486675c43b416cb674e8ece9c147
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
(cherry picked from commit 9768d8e1ba21adace1f590420791e6924a9fad8c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This change adds a new -sbom configure option to allow generating and
installing an SPDX v2.3 SBOM file when building a qt repo.
The -sbom-dir option can be used to configure the location where
each repo sbom file will be installed.
By default it is installed into
$prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx
which is basically ~/Qt/sbom/qtbase-6.8.0.spdx
The file is installed as part of the default installation rules, but
it can also be installed manually using the "sbom" installation
component, or "sbom_$lower_project_name" in a top-level build. For
example: cmake install . --component sbom_qtbase
CMake 3.19+ is needed to read the qt_attribution.json files for
copyrights, license info, etc. When using an older cmake version,
configuration will error out. It is possible to opt into using an
older cmake version, but the generated sbom will lack all the
attribution file information.
Using an older cmake version is untested and not officially supported.
Implementation notes.
The bulk of the implementation is split into 4 new files:
- QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing
and dispatching the generation of various pieces of the SBOM document
e.g. a SDPX package associated with a target like Core, a SDPX
file entry for each target binary file (per-config shared library,
archive, executable, etc)
- QtPublicSbomGenerationHelpers.cmake - for non-Qt specific
implementation of SPDX generation. This also has some code that was
taken from the cmake-sbom 3rd party project, so it is dual licensed
under the usual Qt build system BSD license, as well as the MIT
license of the 3rd party project
- QtPublicGitHelpers.cmake - for git related features, mainly to embed
queried hashes or tags into version strings, is dual-licensed for
the same reasons as QtPublicSbomGenerationHelpers.cmake
- QtSbomHelpers.cmake - Qt-specific functions that just forward
arguments to the public functions. These are meant to be used in our
Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones
for naming consistency. These function would mostly be used to
annotate 3rd party libraries with sbom info and to add sbom info
for unusual target setups (like the Bootstrap library), because most
of the handling is already done automatically via
qt_internal_add_module/plugin/etc.
The files are put into Public cmake files, with the future hope of
making this available to user projects in some capacity.
The distinction of Qt-specific and non-Qt specific code might blur a
bit, and thus the separation across files might not always be
consistent, but it was best effort.
The main purpose of the code is to collect various information about
targets and their relationships and generate equivalent SPDX info.
Collection is currently done for the following targets: Qt modules,
plugins, apps, tools, system libraries, bundled 3rd party libraries
and partial 3rd party sources compiled directly as part of Qt targets.
Each target has an equivalent SPDX package generated with information
like version, license, copyright, CPE (common vulnerability
identifier), files that belong to the package, and relationships on
other SPDX packages (associated cmake targets), mostly gathered from
direct linking dependencies.
Each package might also contain files, e.g. libQt6Core.so for the Core
target. Each file also has info like license id, copyrights, but also
the list of source files that were used to generate the file and a
sha1 checksum.
SPDX documents can also refer to packages in other SPDX documents, and
those are referred to via external document references. This is the
case when building qtdeclarative and we refer to Core.
For qt provided targets, we have complete information regarding
licenses, and copyrights.
For bundled 3rd party libraries, we should also have most information,
which is usually parsed from the
src/3rdparty/libfoo/qt_attribution.json files.
If there are multiple attribution files, or if the files have multiple
entries, we create a separate SBOM package for each of those entries,
because each might have a separate copyright or version, and an sbom
package can have only one version (although many copyrights).
For system libraries we usually lack the information because we don't
have attribution files for Find scripts. So the info needs to be
manually annotated via arguments to the sbom function calls, or the
FindFoo.cmake scripts expose that information in some form and we
can query it.
There are also corner cases like 3rdparty sources being directly
included in a Qt library, like the m4dc files for Gui, or PCRE2 for
Bootstrap.
Or QtWebEngine libraries (either Qt bundled or Chromium bundled or
system libraries) which get linked in by GN instead of CMake, so there
are no direct targets for them.
The information for these need to be annotated manually as well.
There is also a distinction to be made for static Qt builds (or any
static Qt library in a shared build), where the system libraries found
during the Qt build might not be the same that are linked into the
final user application or library.
The actual generation of the SBOM is done by file(GENERATE)-ing one
.cmake file for each target, file, external ref, etc, which will be
included in a top-level cmake script.
The top-level cmake script will run through each included file, to
append to a "staging" spdx file, which will then be used in a
configure_file() call to replace some final
variables, like embedding a file checksum.
There are install rules to generate a complete SBOM during
installation, and an optional 'sbom' custom target that allows
building an incomplete SBOM during the build step.
The build target is just for convenience and faster development
iteration time. It is incomplete because it is missing the installed
file SHA1 checksums and the document verification code (the sha1 of
all sha1s). We can't compute those during the build before the files
are actually installed.
A complete SBOM can only be achieved at installation time. The install
script will include all the generated helper files, but also set some
additional variables to ensure checksumming happens, and also handle
multi-config installation, among other small things.
For multi-config builds, CMake doesn't offer a way to run code after
all configs are installed, because they might not always be installed,
someone might choose to install just Release.
To handle that, we rely on ninja installing each config sequentially
(because ninja places the install rules into the 'console' pool which
runs one task at a time).
For each installed config we create a config-specific marker file.
Once all marker files are present, whichever config ends up being
installed as the last one, we run the sbom generation once, and then
delete all marker files.
There are a few internal variables that can be set during
configuration to enable various checks (and other features) on the
generated spdx files:
- QT_INTERNAL_SBOM_VERIFY
- QT_INTERNAL_SBOM_AUDIT
- QT_INTERNAL_SBOM_AUDIT_NO_ERROR
- QT_INTERNAL_SBOM_GENERATE_JSON
- QT_INTERNAL_SBOM_SHOW_TABLE
- QT_INTERNAL_SBOM_DEFAULT_CHECKS
These use 3rd party python tools, so they are not enabled by default.
If enabled, they run at installation time after the sbom is installed.
We will hopefully enable them in CI.
Overall, the code is still a bit messy in a few places, due to time
constraints, but can be improved later.
Some possible TODOs for the future:
- Do we need to handle 3rd party libs linked into a Qt static library
in a Qt shared build, where the Qt static lib is not installed, but
linked into a Qt shared library, somehow specially?
We can record a package for it, but we can't
create a spdx file record for it (and associated source
relationships) because we don't install the file, and spdx requires
the file to be installed and checksummed. Perhaps we can consider
adding some free-form text snippet to the package itself?
- Do we want to add parsing of .cpp source files for Copyrights, to
embed them into the packages? This will likely slow down
configuration quite a bit.
- Currently sbom info attached to WrapFoo packages in one repo is
not exported / available in other repos. E.g. If we annotate
WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be
available when looking up WrapZLIB in qtimageformats.
This is because they are IMPORTED libraries, and are not
exported. We might want to record this info in the future.
[ChangeLog][Build System] A new -sbom configure option can be used
to generate and install a SPDX SBOM (Software Bill of Materials) file
for each built Qt repository.
Task-number: QTBUG-122899
Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 37a5e001277db9e1392a242171ab2b88cb6c3049)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The QtFindWrapHelper.cmake file retrieves the version of the
underlying system package version or bundled package version, and
passes that to find_package_handle_standard_args to show which version
was found.
But it did not set a ${PACKAGE_NAME}_VERSION variable, which means
we didn't record the version in qt_find_package, and thus in the final
SBOM.
Make sure we set the variable.
Amends 7ad8c347feb5e336c3833d6d3ac021a0a14b714a
Change-Id: Ia0d5b895de36017949e6607d17093459dca302b3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 0be79f14865c0a19fde0abad7d1722f0bac3b7c2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Use the variable name but not the unwrapped value.
Pick-to: 6.7 6.5
Change-Id: Ie392a4875fe412b8eb273a457a83cd08cd9f5e15
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit e960fb136e77437e158367f86bc926504e0fdab6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The behavior that argument was enabling is the default one now.
Task-number: QTBUG-90492
Change-Id: I11711d4c794f0b22169abb595b8ffad2eeb1300d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 1ef3bd05eb45d53cdcf92b933603b995283b3432)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Consider a feature that has ENABLE and CONDITION expressions. For
example, system-libb2 on a Linux machine that does not have the
libb2-dev package installed:
qt_feature("system-libb2" PRIVATE
LABEL "Using system libb2"
CONDITION Libb2_FOUND
ENABLE INPUT_libb2 STREQUAL 'system'
DISABLE INPUT_libb2 STREQUAL 'no' OR INPUT_libb2 STREQUAL 'qt'
)
If the feature is enabled by the user by setting
FEATURE_system_libb2=ON, then there's an error:
Feature "system_libb2": Forcing to "ON" breaks its condition...
This is expected.
If the feature is enabled by the user by triggering the ENABLE condition
via the -system-libb2 configure flag (that sets INPUT_libb2 to
"system"), we did not get an error message.
This was unexpected and inconsistent.
Now, we consider features that are enabled via their ENABLE condition as
set by the user and yield an error if the CONDITION doesn't match.
Fixes: QTBUG-126144
Change-Id: I249baf9ab4f434f5a96894f4ec055f70859ffca9
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit ad227368c3ab3a9dc68208bce2d075edefe7e6e0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
If the forward argument was meant to be 0, it was not forwarded
because it evaluated to false in if(condition).
To pass it along, instead check for empty strings.
Change-Id: Ia366df147de0c2d333017da43dc0643b56a89e9c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 96abceb64e5dc0570ca7c3419f401cfafe946ba0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
If a build dir is removed using rm -r *, this still leaves
dot files around, specifically the .ninja_log file.
Because of a possibly unspecified behavior of listing directories as
OUTPUTs in a add_custom_command call for the
${target}_copy_fw_sync_headers custom target, we end up with a
situation where the custom command is not rerun by ninja because the
directory OUTPUT was encountered in the .ninja_log file.
Make sure to specify an additional file as an OUTPUT, to ensure the
command does rerun, and thus copies all headers from the syncqt
staging directory.
Amends 103eca1070
Pick-to: 6.7 6.5
Fixes: QTBUG-126056
Change-Id: I5664cf074158199e0c7fd5e312ecf739133d7f2e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit c561bcceed0300a14e2062958afce62776be4b6f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Due to QTBUG-125371 we currently record Qt6 as a third party
dependency for many qt packages.
Until that is fixed, we should not record the provided targets of the
Qt6 package, because it causes issues during SBOM generation.
Amends 58eefbd0b6
Task-number: QTBUG-125371
Change-Id: I35d548996c3820aaa7a1175b3a1f34c23ec2290f
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
It's a helper to pass along option arguments that are set by
cmake_parse_arguments, from the current scope to another function
call.
It avoids a lot
if(arg_FOO) set(options FOO ${arg_FOO})
boilerplate.
It is somewhat the opposite of _qt_internal_remove_args.
The options that the function takes are prefixed with FORWARD_
to avoid possible naming conflicts with the actual options that should
be forwarded.
Change-Id: I54fd22b884d8af8379f2f735eb911a3bc66d3416
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Each qt_find_package can specify a PROVIDED_TARGETS option, to inform
which targets will be created by that package.
The call then saves the package name, version, etc on each of the
provided targets.
Currently the provided targets info is not persisted anywhere after
configuration ends.
We will need this for SBOM creation, so that we can collect
information about such dependencies when configuring leaf
repos, where find_dependency calls are implicit, and don't contain
the PROVIDED_TARGETS option, and we need to go from package name to
target name (and any recorded info it the target has).
This is especially relevant for static library builds, where private
dependencies become public dependencies.
Collect the provided targets information at post process time and
persist it for each 'package name + components requested' combination
into the Dependencies.cmake file.
This information will be used in a later change for SBOM generation.
Change-Id: I1693f81b1ad3beaf9b02e44b09a5e977923f0d85
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Piotr Wierciński
Alexandru Croitor
Alexey Edelev
Joerg Bornemann
Li Xinwei
Tor Arne Vestbø
Thiago Macieira
Morten Sørvig