The function append the unique entries to the CMAKE_CONFIGURE_DEPENDS
property. This suppress the ninja recompat issue, which complains
about the duplicated entries in that come from the
CMAKE_CONFIGURE_DEPENDS property. It's likely the CMake issue, but
we may work around it.
Pick-to: 6.8 6.9 6.10
Change-Id: I2f10834b0dca3d2aa08fe13fba69849e97fa77d0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The function sets properties on target that then are propagated
transitively. This only works with Qt modules, but can be extended
for other Qt targets later. These transitive properties not necessarly
require Qt be built using CMake versions supporting transitive
properties(>= 3.30). Properties are stored and exported within the
Qt module unconditionally and can be used in user projects, if
CMake version allows this.
Change-Id: I1ff6f1099753784c721dc1e3cd972dcd9dafedc4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This file sets the transitive module properties provided by
Qt Module that is built using CMake versions < 3.30. The idea
is to not limit user projects capabilities and allow using
transitive Qt Module properties if user CMake version allows it.
If Qt Modules are built using CMake versions >= 3.30 this code is noop,
since values are stored directly in the respective
INTERFACE_properties.
Change-Id: I5a0bc0aa4f79a04c81dfa0fee1d37cfee5935b0f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Before this change, if someone called ninja Gui_generate_docs, it
would implicitly depend on sync_all_public_headers -> Gui_sync_headers
which would generate dbus headers.
This caused trouble with the new 'build doc tools from
qttools/dev/HEAD' approach, because an older pre-built dbus tool might
be passed a newer option when integrating a qtbase change that passes
the new option.
To avoid that, we now filter out the dbus headers from the list of
headers that should be processed by syncqt when building a
documentation target.
We do the same for the qvkgen generated headers.
This also removes the dependency on the ${target}_sync_headers target,
which means there is a potential issue when someone manually calls
`ninja sync_all_public_headers Gui_sync_headers` or something like it,
which would spawn two syncqt processes that access the same files
concurrently. This is an edge case that should not happen, but if it
ends up happening, we will have to implement some kind of lock file
mechanism.
Pick-to: 6.8 6.9
Fixes: QTBUG-134672
Task-number: QTBUG-128730
Change-Id: I9061f9495e2faa77744f5f5c0de8fedd362ba228
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
When a Qt module Foo links against a Qt module Bar then we add the
${QT_BUILD_DIR}/include/QtBar/QtBar header to the list of precompiled
header files. However, this only works if Foo and Bar are in the same
build system, e.g. in the same repository or in a top-level build. For
example, the QtCore header was never precompiled when in a per-repo
build of QtSvg.
Now, we determine whether Foo and Bar are in the same build system. If
they are, we proceed as before. Otherwise, we calculate the QtBar
header's location from the following data:
- the location of Qt6BarConfig.cmake
- the relative path to Bar's include directory
The Q*Application tests' project files had to be adjusted to use
NO_PCH_SOURCES now, because they use the source file
apphelper_plugin.cpp that specifically checks that pre-compiled headers
are not used for its compilation.
Fixes: QTBUG-134424
Change-Id: I04ede51e4d853e8b813f660f29be8cfeb684c0b2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Not sure why it worked at implementation time. But now it definitely
doesn't. We may check the EXCEPTIONS flag value, since it's the
equivalent of its presence/non-presence in the argument list.
Amends f98fd705290ac7bd9434552a07e38b775e6a6dbf
Task-number: QTBUG-118901
Pick-to: 6.9
Change-Id: I9769b4921a2f72d31aea2b0bffd2511edd89f88f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Private modules without private headers don't make much sense and
needlessly create CMake packages and QMake module pri files.
In qt_finalize_module we check whether the module has any private
headers. But the private module was already created before in
qt_internal_add_module. Moving the creation of the private module or the
CMake package files to the finalization phase would be a bigger
refactoring that's probably not worth the hassle.
An easier way to avoid the package creation issue is to mandate that a
Qt module must be created with NO_PRIVATE_MODULE if it doesn't have any
private headers.
Add a warning if a Qt module without private headers is created without
NO_PRIVATE_MODULE. Also warn if a Qt module with private headers is
created with NO_PRIVATE_MODULE.
This allows us to easily spot the places where NO_PRIVATE_MODULE is
missing.
Task-number: QTBUG-132526
Change-Id: I897f25790a99eaa320c39cd8c2728f26bceb824e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
On macOS, Core has plugins that link against CorePrivate. In a
non-prefix build, user projects failed on find_package(Qt6 REQUIRED
COMPONENTS Core), because CorePrivate is required for these plugins in
a non-prefix build, but it's not automatically pulled in.
This is only an issue for CMake < 3.26, because these older CMake
versions lack the BUILD_LOCAL_INTERFACE generator expression.
Fix this by pulling in the private modules for non-prefix builds when
using CMake < 3.26. Also, issue a warning in this situation.
Fixes: QTBUG-134407
Change-Id: I7f182c9518686390e657663b452cad8101d870a2
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If the source file sets `QT_INSTALL_PATH` property, it will install the
CMake files in the relative path starting from the config-dir in both
the build and install paths.
Pick-to: 6.8 6.9
Change-Id: I86197d62bfac96f9c142d8abfe85c9b6f6f1a527
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The issue was fixed by commit
3b0dab39d047cfc676a75915ce606cbd4d43a83d in qtdeclarative.
This reverts commit 4d95b6dccdd7772594bdb5f0c404585f16a4dc9c.
Change-Id: Ic7d78e740d1789a4ebd1d4c8c91d18846e005dfe
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The SBOM functions so far had a lot of Qt-specific logic inside them.
Decouple this logic into separate Qt-specific functions or explicitly
guard the code with Qt-specific handling options, to prepare for a
cleaner SBOM public API.
The generic functions then call the Qt-specific ones if various
internal options are set.
This approach is used, rather than directly passing values to the
generic functions because:
- we have cases where we need to recursively pass the values all the
way down to all recursively created attribution targets
- some of the logic needs to know about values before and after qt
processing, and this could be achieved with something like lambdas
but it's not worth the complexity
Pick-to: 6.8 6.9
Task-number: QTBUG-122899
Change-Id: I4399c41f4d976f20b16a0bb0c674d4f07ee1ccd4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We temporarily enable automatic find_package of Qt6FooPrivate whenever
Qt6Foo is find_package'ed, because
1. Currently, Qml user projects are broken unless they set
QT_FIND_PRIVATE_MODULES=ON.
2. The fix for qtdeclarative depends on the submodule update.
3. The submodule update is blocked by QTBUG-133352.
This fixes Qml user projects for people who use latest dev in all repos.
Change-Id: I2c2907e531e908515b51eae1ea90df555e40871e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add FIND_PRIVATE_MODULE argument to qt_internal_add_module. If this
argument is set for Qt6Foo, then find_package(Qt6Foo) will also
find_package(Qt6FooPrivate). This should only be necessary in
exceptional cases like Qt6Qml where Qt6QmlPrivate is used
unconditionally.
Task-number: QTBUG-87776
Change-Id: I8d6fbd0624c0008fc42294ff2d2ed36848963508
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
A project might want to find_package all available (installed) Qt CMake
packages that contain qt modules.
A use case might be a qml app that needs to link to all of Qt, and
support showing qml files that can load any Qt qml module.
Add a new Qt6 COMPONENT called ALL_QT_MODULES.
It can be used like this:
find_package(Qt6 COMPONENTS ALL_QT_MODULES).
The implementation will find all installed Qt modules by globbing over
all json files installed in $qt/modules dir, and treat the file names
as package names.
It will then tell Qt6 to find_package each of those packages.
Pick-to: 6.8 6.9
Change-Id: I89242307438576a0cbb3cdca80a9cb72818b6035
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
[ChangeLog][CMake] CMake packages of public Qt modules don't provide the
targets of their private counterparts anymore. User projects must now
call find_package(Qt6 COMPONENTS FooPrivate) to make use of the
Qt6::FooPrivate target. User projects that rely on the old behavior can
set the CMake variable QT_FIND_PRIVATE_MODULES to ON.
For user projects, the warning message we know from QMake is displayed.
The warning can be disabled by setting the CMake variable
QT_NO_PRIVATE_MODULE_WARNING to ON.
Within Qt itself, find_package(Qt6Foo) will still
find_package(Qt6FooPrivate).
For static Qt builds, we need to wrap usage of private Qt modules in
$<BUILD_INTERFACE> or $<BUILD_LOCAL_INTERFACE> (if CMake's version is >=
3.26). Static builds with CMake < 3.26 will always load the private
modules if the Qt6FooConfig.cmake from Qt's build tree is loaded. This
is the case in non-prefix builds and (in the future) when building
examples as external project.
This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f.
Pick-to: 6.9
Task-number: QTBUG-87776
Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qt_register_target_dependencies does the same thing as
qt_record_extra_qt_package_dependency but in more convenient way.
Update the qt_register_target_dependencies signature and adjust naming,
it now accepts PUBLIC and PRIVATE multi-value arguments and called
qt_internal_register_target_dependencies.
Use it and deprecate qt_record_extra_qt_package_dependency.
Pick-to: 6.5 6.8 6.9
Change-Id: I0594cf699ec1e3af7210dd7450fa3f81c1f565ae
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f.
Remove the EXTRA_PACKAGE_DEPENDENCIES argument that was added in
mentioned commit, and use the qt_register_target_dependencies function
instead to add the package dependency Qt6FooPrivate -> Qt6Foo.
Pick-to: 6.9
Task-number: QTBUG-87776
Change-Id: I08a48954576dc3c0b6fde809f90d2022201d7eb0
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
[ChangeLog][CMake] Private Qt modules have been split off into separate
Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will
now implicitly find_package(Qt6FooPrivate). It's not an error if
Qt6FooPrivate isn't available as it may be the case on certain Linux
distros that split their Qt module packages into private and public
parts.
For every public module Qt6Foo that has an associated Qt6FooPrivate
module, create a separate Qt6FooPrivate CMake config package.
Let Qt6FooPrivate find Qt6Foo. This is a required dependency.
Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level
VERBOSE is issued if Qt6FooPrivate is not found.
Implementation notes: In QtModuleConfig.cmake.in, we pull in the private
module. This is not part of the *Dependencies.cmake file, because
1. The Qt6FooPrivate package references the Qt6::Foo target, therefore
it must be available. And Qt6FooDependencies.cmake is loaded before
creating targets.
2. The dependency needs to be optional, and we don't have facilities for
optional dependencies in Qt6FooDependencies yet.
3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo
dependency.
Fixes: QTBUG-87776
Pick-to: 6.9
Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The list of available QPA platforms and the default QPA platform is now
available in modules/Gui.json.
Change-Id: I059286d80c8507080d5ec3d790cf8ea22c5daddd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The linked issue reports a lack of information about multi-arch builds
of Qt on Apple platforms. In order to add the information we take the
chance to rework the structure of the module JSON files and make the
format future-proof for when we'll create multi-platform
bundles (xcframeworks).
The new module JSON files differ from the old ones in the following
points:
- The 'schema_version' key denotes the version of the module JSON file
schema. It's set to 2.
- The 'built_with' key was removed. The relevant information was moved
to 'platforms' entries.
- The 'cross_compiled' key was removed. It was only used to determine
whether a Qt build contained host tools. Since one needs the actual path
to host tools anyway, it's more useful to query qtpaths for that
information.
- A 'platforms' key was added that holds a list of target platforms.
Currently, only an iOS simulator-and-device build has more than one
platform:
"name": "iOS",
"variant": "iphoneos",
and
"name": "iOS",
"variant": "iphonesimulator",
- A 'targets' key was added under each 'platforms' entry. This contains
information about the target architecture(s) and other relevant
properties.
- The 'android' key was flattened and moved to the 'targets' entries.
[ChangeLog][CMake] The structure of the module JSON files, e.g.
modules/Core.json has been reworked. Consumers of these files need to be
updated. A 'schema_version' key was added and set to 2 to ease reading
different versions of these files.
Fixes: QTBUG-129996
Change-Id: I5a6ac9746aa19ad0ee9f2d020bf7486bdac28226
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use the freshly introduced TRANSITIVE_COMPILE_PROPERTIES functionality
to handle plugin targets across Qt modules. This will allow accessing
all Qt plugins that are required for targets at once, without the need
of iterating over the Qt targets at configure time.
This mechanism duplicates the already existing plugin collecting
routines, since we still need to support the older CMake version.
This commit only introduces the helper functions and plugins collecting,
but doesn't use the QT_PLUGIN_TARGETS anywhere.
We don't use the direct export of properties by CMake but still rely on
plugin collecting mechanism we use before to cover the situation when
Qt is built using CMake versions < 3.30 and then is used to build user
applications with CMake versions >= 3.30.
Task-number: QTBUG-129302
Change-Id: Id3b516b92e8e16552d46b2c702b76c571366f2b5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMake 3.31 introduced CMP0177 that warns if an install destination is a
not-normalized path. Fix this by normalizing the offending paths before
using them.
Pick-to: 6.8
Change-Id: I1586bf192a4fd26108aa0448431f19e69df8aacd
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
CMake 3.31 introduced the policy CMP0174 that triggers a warning if a
single-value argument is passed to a function without a value.
We did this doing this when forwarding arguments in code that doesn't
use _qt_internal_forward_function_args yet, e.g. in qt_internal_add_app:
qt_internal_add_executable(...
TARGET_PRODUCT ${arg_TARGET_PRODUCT}
...)
Forward the warning-triggering arguments with
_qt_internal_forward_function_args now, because that only forwards used
arguments.
In the future, we can offload more forwarding work to the
_qt_internal_forward_function_args command and simplify the forwarding
code in qt_internal_add_app and qt_internal_add_tool. This patch only
fixes the worst offenders for now.
Pick-to: 6.8
Change-Id: Ie786691e4b236decf4c62f4dd0751ed76b721177
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
It appears that the VxWorks linker behaves similarly to GNU ld, where
the order of link libraries on the command line matters.
Our plugin linking system is not ideal (due cycles like Gui -> plugin
-> Gui, or Qml -> qml plugin -> Qml), and can change the order of
the linked libraries on the command line.
Due to that, some of the qtdeclarative tests fail to link with
undefined symbols in Qml.
Apply the same workaround we did for Linux, which is to increase the
LINK_INTERFACE_MULTIPLICITY of Qt modules to 3, effectively ensuring
that each qt module static library appears at least 3 times on the
link line, given the linker more chances to find relevant symbols.
Amends 58a7e4f0bc5e9290cc205762d51adc5806b034fd
More in detail reasoning explained in commit message of
69b27e09f55e63a713ca8b14f162d4f449c8dfff in qtquick3d
Pick-to: 6.8
Fixes: QTBUG-129113
Task-number: QTBUG-83498
Change-Id: I7ac5665d4dd2865584ba1c96d51fd311ef224d10
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Amends 8d2d5563b5a02c6c3dee23c35cda4efcfb87a33f.
Core.json was using the older name variable name
QT_ANDROID_API_VERSION instead of the new name
QT_ANDROID_API_USED_FOR_JAVA.
Change-Id: I1c995818331f45eedb07114276b6aba0f6577c15
Reviewed-by: Shyamnath Premnadh <Shyamnath.Premnadh@qt.io>
Add the WARNINGS_ARE_ERRORS flags unconditionally, so developers may
control skipping per-target or per-repo.
This allows setting the WARNINGS_ARE_ERRORS cmake option for each repo
independently when configuring them. So qtbase might be built without
the flag enabled and setting the WARNINGS_ARE_ERRORS to TRUE for
the depending repo enables it for the internal Qt targets.
Add the new internal function that controls the related internal flag.
Keep qt_skip_warnings_are_errors for compatibility since it's used
in qtwebengine.
Combine qt_internal_set_skip_warnings_are_errors and
qt_skip_warnings_are_errors_when_repo_unclean functionality in the
new qt_internal_default_warnings_are_errors function.
Change-Id: I1330c75cd67a24e6386f5e94a089e43fa2012bc4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
They should inherit the version of the 3rd party library they are part
of, and not be treated as Qt modules.
Pick-to: 6.8
Task-number: QTBUG-122899
Change-Id: Ibf99f4481fbc1acca488fc96cca048298b080d35
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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
Pick-to: 6.8
Change-Id: I974f95ca0f26085dd0fe5ceb8bbef4f62467979a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The feature allows enabling/disabling exceptions for the Qt builds.
The feature is disabled by default.
This commit reworks the way the exception flags are set for Qt targets.
Instead of setting them per-target, flags now are set for the
QtPlatformCommonInternal target, which transitively propagates the flag
to other Qt targets. To disable/enable exception flags the newly
introduced property _qt_internal_use_exceptions can be used. The flags
enabling/disabling now can happen any time, but not only at target
creation time. The property has 3 states: TRUE, FALSE, DEFAULT(or
empty). If the property is not set or is set to DEFAULT, the exceptions
feature value is used to set the required exceptions flags. Otherwise
the flags are set according to the property value.
The logic of EXCEPTION argument of the various qt_internal_add_
functions was also updated. If the argument is not provided, the
_qt_internal_use_exceptions property value is set to DEFAULT, which
gives the control on the exception flags to the feature. If the
argument is provided, the exceptions are enabled by setting the
_qt_internal_use_exceptions property to TRUE.
Task-number: QTBUG-118901
Change-Id: I83e3bf52d48a3d16977cce849c9b0765c34f1f21
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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.
Pick-to: 6.8
Task-number: QTBUG-122899
Change-Id: I6eb723e165edf59973d83c66eace43acdce237de
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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.
Pick-to: 6.8
Task-number: QTBUG-122899
Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Use the variable name but not the unwrapped value.
Pick-to: 6.5 6.7 6.8
Change-Id: Ie392a4875fe412b8eb273a457a83cd08cd9f5e15
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The behavior that argument was enabling is the default one now.
Pick-to: 6.8
Task-number: QTBUG-90492
Change-Id: I11711d4c794f0b22169abb595b8ffad2eeb1300d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Calling qt_internal_get_framework_info failed when the target was
an INTERFACE_LIBRARY, because it tried to access properties that
aren't allowed on such a target. Interface libraries can't be
frameworks, so just add an early return guard.
Do the same for qt_internal_apply_apple_privacy_manifest.
Change-Id: I85b73449a0d56b92cd01b032d4ce5db905643c9f
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The new approach allows to imply the macro definitions for every Qt
submodule and user project without the need of setting it explicitly
from CMake. This also prevent users from introducing the
incompatibility between Qt modules due to defining
the QT_DISABLE_DEPRECATED_UP_TO version lower than qtbase was built
with.
Task-number: QTBUG-124765
Change-Id: I7ba481f62cb9073ae0343c400ffc26f239f080f1
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
'headersclean' shoudn't be a feature. The respective flag should behave
like command-line switch that affects the only repo that it was passed
for. This also avoids propagating of the headersclean feature between
the different repos when qtbase was built with the headerclean enabled.
Fixes: QTBUG-121722
Change-Id: I304cbc980b06030513c015a2016678a6a0965fed
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Otherwise the touched files will not be re-copied and re-installed
until an explicit rerun of cmake.
Pick-to: 6.7
Change-Id: I5abb752b45d8b33885a59363fe987225a89e713a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Versionless targets in Qt6 are interface libraries that link the
versioned libraries using the INTERFACE link type. This makes the
linking chain more complicated than it can be. Also we miss some
significant interface properties in the versionless targets comparing
to the versioned targets.
The new approach manually generates the versionless targets, instead
of using CMake exports.
For CMake versions < 3.18 we now create a copy of the versioned
targets. The copy includes all the relevant INTERFACE properties from
the versioned targets and imported locations for all configs.
For CMake versions >= 3.18 we now create the versionless target ALIASes
which should behave give the transparent access to the versioned
targets.
Using the QT_USE_OLD_VERSION_LESS_TARGETS flag you may force the
behavor of the CMake versions <= 3.18
The change is partial workaround for QTBUG-86533.
Task-number: QTBUG-114706
Change-Id: Iafadf6154eb4912df0697648c031fcc1cbde04e0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The default manifest is a minimal file that claims NSPrivacyTracking
false, along with an empty list of NSPrivacyTrackingDomains and
NSPrivacyCollectedDataTypes, as Qt does not generally do user tracking.
Modules can override the default manifest by setting the
PRIVACY_MANIFEST target property, specifying a custom privacy
manifest.
The NSPrivacyAccessedAPITypes key is only required for iOS for now.
Even though we don't build Qt for iOS as frameworks yet, which is
required to embed a privacy manifest, we include the keys for the
APIs we known we use.
Task-number: QTBUG-114319
Change-Id: I654bb52b98ee963adeeb744b35f3a1c2a1270969
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The argument is inverted GENERATE_CPP_EXPORTS argument. Use it
explicitly for the modules that do not require the autogenerated cpp
exports.
Task-number: QTBUG-90492
Change-Id: Ic67772ba9ed5e40f132a97e7d6844102ad023ff3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It looks like we don't even support nested namespace(RCC namespace
mangling fails). Assuming that QT_NAMESPACE should be
the valid C/C++ indentifier.
Change-Id: I5c2073c21964eb96abb3e894d83e1df65f7730b4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The perivous version generated weird condition, and seems changing
the QT_NAMESPACE after qtbase configuration is noop, we may replace
the generated condition with the conditional generation.
Change-Id: Ifa09dba4db00099a07da2cff5505e6fd0b008289
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The QtQuick3D semi-public headers were not installed correctly due to a
typo in QtModuleHelpers. This amends 9c3c87f6d0d5c70b9
Change-Id: Iec6ed4e1785fbb1189385104f476c37481ef47fb
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
