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
Task-number: QTBUG-122899
Change-Id: I4399c41f4d976f20b16a0bb0c674d4f07ee1ccd4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit f1ac316191c010b1389f6f3549c9f0b4424b9936)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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.8 6.5
Change-Id: I0594cf699ec1e3af7210dd7450fa3f81c1f565ae
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 8272b747d3b91e15fda2b76326221a26fb2245d2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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>
The object libraries that are side products from building plugins
should also consider the properties that control the flag handling of
their main plugin targets, otherwise they will inherit the
PlatformInternal flags without knowing what their parent decide.
Functionality now considers QT_SKIP_WARNINGS_ARE_ERRORS and
_qt_internal_use_exceptions properties. The list can be extended in the
future.
Change-Id: If304b3b382d6cd05064bc87e11d3cc87ba7c0d7b
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
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>
When configuring standalone tests with some installable plugins, these
plugins land inside the actual build/install directory after
build/installation. This makes imposible to configure the same
standalone tests second time since the same plugin targets attempt to
be created within the build tree, while they are already found by the
respective find_package(<Qt Module>) call.
This change introduces and uses the tests-wide
qt_internal_configuring_tests variable to mark the plugins that are
built within the tests build tree and disallows loading them by the
find_package call when building standalone tests.
The trick is simple: PluginConfig.cmake files skip plugin creation if
the respective plugin is a test plugin and the standalone test project
matches the plugin repo project.
Also we now oblige module maintainers to mark such plugins using the
TEST_PLUGIN argument of the qt_internal_add_plugin function. This is
needed to prevent breakage when the exact test is build alone and the
qt_internal_configuring_tests is not set. If plugin is not marked as
TEST_PLUGIN and is built as part of test build tree the warning is
displayed to remind the maintainer about the missing flag. Suggest to
make this flag mandatory for all test plugins, and throw a FATAL_ERROR
if the plugin is not marked respectively.
Fixes: QTBUG-127781
Change-Id: I51f8b2f2c979911dad7c90926d841c8b8f1bb5d7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
Commit 87896c03c1baccff0049b582dcbf512716aeb8bc introduced a static
imageformat plugin that is not installed, because it's used exclusively
by an autotest. We must not generate .pri files for such plugins.
Otherwise, QMake projects will try to link against this plugin, which
does not exist in the Qt installation.
Fixes: QTBUG-126393
Change-Id: I3abf25a2ea98eee2b054524dd85443580a9ed9a8
Reviewed-by: Alexey Edelev <alexey.edelev@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>
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>
Qt tools and executables may required the static plugins from modules
that are build as part of the Qt build tree. In this case we need to
force plugin importing. This adds the qt_internal_import_plugins call
when we extend the executable target.
Replace the previos solution that considered libraries that were
provided in the arguments of the qt_internal_add_executable call only.
Pick-to: 6.7 6.6 6.5
Fixes: QTBUG-111988
Change-Id: Ifa2cf7f1f68d9f90cafc64f225aebe11d4cdb2ae
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMake-3.29 supports unity-building of objc/objcpp. This patch fixes
darwin's permission helper, which includes a source under a preprocessor
define.
Change-Id: I62e2d291c40ad7b1dbb5243eaee9bf8625473041
Pack-to: 6.7 6.6 6.5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Make sure that plugin_init_target is not empty. It's empty when
creating qml plugins.
Amends 566b726b8400d473861a62b4b9de87d1f0958d6d
Pick-to: 6.7
Change-Id: If23998d50d8d31e20b3966730afb8b4b46b9990c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
When building tests in-tree targeting iOS, we run
_qt_internal_finalize_executable via
qt_internal_add_test_finalizers.
This in turn calls __qt_internal_apply_plugin_imports_finalizer_mode
which tries to link to versioned plugin int targets.
Because the linked plugin init target is built in-tree as well, and
did not have versioned alias targets created, configuration fails
with:
Target "tst_baseline_qsvgrenderer" links to:
Qt6::QSvgIconPlugin_init
but the target was not found.
Make sure to create versioned alias targets for the plugin init
targets.
Amends 6c9f4f5ebcd35dc1a68c442d9fbf3ec48f30baca
Pick-to: 6.7
Fixes: QTBUG-123186
Task-number: QTBUG-122181
Change-Id: I0048b724d465dc3c176d238d144feb072262d76e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This covers the following use case:
QtModuleX is pre-built and installed, it's imported. The plugin has
a PLUGIN_TYPE that is associated with QtModuleX and is built with
application that links QtModuleX. When deploying the application
it's expected that the plugin is deployed, as the one that belongs
to the linked QtModuleX.
This ensures that we udpate the internal _qt_plugins property that
is used in the __qt_internal_collect_plugin_targets_from_dependencies
function.
Pick-to: 6.5 6.6 6.7
Change-Id: I9824351ebab5a24509800da4db69f1e282a35884
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The former implies the latter, so it makes little sense to treat them
differently. Even if some types of targets are (currently) never
compiled with PCH, users of qt_internal_all_x() shouldn't need to know
such details.
Pick-to: 6.6 6.5
Change-Id: I8ead238a8d9e55da632b2929638b67724a42d73c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The source of the problem was in `qt_set_target_info_properties` which
was not able to process the NO_UNITY_BUILD_SOURCES, and therefore
leaking it into the `TARGET_COPYRIGHT`, ie., the last argument. So, I
decided to pass Unity Build arguments before them, and closer to
SOURCES, which is nicer to read, and avoid similar situation. And
I reverted the work around in the amend commit, and passing the
arguments normally.
This happens because we pass an unfiltered ${ARGN} from
qt_internal_add_executable to qt_set_target_info_properties and that the
current change is merely a workaround that ensures they get
circumstantially filtered out, because the NO_UNITY_BUILD_SOURCES option
appears before any of the first TARGET_ props.
Amend cd12c1f33281452d478bb94744d76bead5c7363a
Task-number: QTBUG-99238
Task-number: QTBUG-109394
Pick-to: 6.5
Change-Id: Idb37937cf53e708425402c90f55bda8816e27f29
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When doing a top-level build with ExternalProject examples, it doesn't
make sense to make qtbase examples depend on e.g. qtdeclarative
plugins. Instead the qtbase example should only depend on plugins
built in qtbase.
Create per-repo custom targets that depend on all plugins built within
that particular repo.
Create an additional per-repo target which depends on all
plugins built in that repo, as well as plugins from dependent repos.
Use the latter as a dependency for examples built as part of the
current repo.
Repo dependencies are parsed from dependencies.yaml.
Pick-to: 6.5
Fixes: QTBUG-110913
Change-Id: I149860cc549caf53271c9ea296eb7bac2a663715
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
- The following commands accepts NO_UNITY_BUILD, and
NO_UNITY_BUILD_SOURCES arguments to opt out of the unity build, and
to exclude some source files from unity build, respectively.
- qt_internal_add_executable
- qt_internal_add_module
- qt_internal_add_plugin
- qt_internal_add_tool
- qt_internal_extend_target
- qt_internal_add_common_qt_library_helper
- qt_internal_add_cmake_library
- qt_internal_add_simd_part
- Unity build is disabled by default in these:
- qt_internal_add_test
- qt_internal_add_test_helper
- qt_internal_add_benchmark
- qt_internal_add_3rdparty_library
- qt_update_ignore_pch_source also excludes the files from unity_build
Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: I5d0e7df633738310a015142a6c73fbb78b6c3467
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The extra quote enforces the arguments to be string, and stops the
COMMAND_EXPAND_LISTS within
QtDbusHelpers.cmake::qt_create_qdbusxml2cpp_command from expanding it
as a list.
Fixes: QTBUG-110459
Fixes: QTBUG-110450
Task-number: QTBUG-99238
Change-Id: Ifddd6570c7bf8f2d1757f275d9445ce2924a93f1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This replaces the qt_parse_all_arguments macro with the built-in
`cmake_parse_arguments(PARSE_ARGV`. In addition, a new function,
_qt_internal_validate_all_args_are_parsed, can be used to check whether
any _UNPARSED_ARGUMENTS have been passed to the function.
Fixes: QTBUG-99238
Change-Id: I8cee83dc92dc6acdaaf747ea6ff9084c11dc649b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We must explicitly set the GENERATED property on source files we
generate.
This amends commit f0a7d74e1dd2c1d802aa09d7b8c144599f4a54ce.
Change-Id: Ifab405cd98deece49a1566ae04220e2b5d576429
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This allows one to add an extra set of directories to the build, but let
the compiler know that they are system paths (that is, the compiler
should refrain from emitting warnings in code found there). This extends
INCLUDE_DIRECTORIES and is by necessity a private include set.
Will be used by qtquick3dphysics, due to its PhysX dependency.
Change-Id: I76216ced393445a4ae2dfffd1729c556db0cce3d
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
When submitting applications to the iOS and macOS AppStore the
application goes through static analysis, which will trigger on
uses of various privacy protected APIs, unless the application
has a corresponding usage description for the permission in the
Info.plist file. This applies even if the application never
requests the given permission, but just links to a Qt library
that has the offending symbols or library dependencies.
To ensure that the application does not have to add usage
descriptions to their Info.plist for permissions they never
plan to use we split up the various permission implementations
into small static libraries that register with the Qt plugin
mechanism as permission backends. We can then inspect the
application's Info.plist at configure time and only add the
relevant static permission libraries.
Furthermore, since some permissions can be checked without any
usage description, we allow the implementation to be split up
into two separate translation units. By putting the request in
its own translation unit we can selectively include it during
linking by telling the linker to look for a special symbol.
This is useful for libraries such as Qt Multimedia who would
like to check the current permission status, but without
needing to request any permission of its own.
Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Change-Id: Ic2a43e1a0c45a91df6101020639f473ffd9454cc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
syncqt.pl adds an extra dependency on perl when building Qt. Modern C++
provides the convenient cross-platform way to access a filesystem and
to use regular expressions, so we may replace the perl script with C++
application. The syncqt executable is built at configure time and
installed as QtCore tool. It's running at configure time to deliver the
required header files for IDE to build a consistent code model and at
the build time to keep tracking changes in header files and generate
the missing aliases without reconfiguring. 'syncqt' only parses header
files from a CMake build tree, so the resulting Qt installation only
contains interfacing headers that belong to the platform that Qt is
built for. 'sync.profile' files are not used as the 'source of truth'
for sync qt procedure anymore, all the necessary information is taken
from either CMake files at configure time or from the module header
files while parsing them.
syncqt.pl is still in place since it's required as fallback solution
for a smooth transition to the new syncqt implementation for all qt
repositories.
This patchset only enables the C++ based syncqt for 'qtbase'
repository.
From the performance perspective C++ version works faster then perl
script, also the configure time is reduced significally on subsequent
reconfigurations - up x2 times faster when re-configuring repository,
but it also takes time to compile the tool itself the first time.
Numbers for qtbase:
syncqt.pl syncqt.cpp
initial: 0m16,035s 0m20,413s
reconfig: 0m6,819s 0m3,725s
The syncing procedure can be run separately for each module using
<ModuleName>_sync_headers targets. The 'sync_headers' target can be
used to sync all the modules at once.
Task-number: QTBUG-87480
Task-number: QTBUG-103196
Change-Id: I8c938bcaf88a8713b39bbfd66d9e7ef12b2c3523
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The same way qt_generate_module_pri_file does it.
Change-Id: I42047ce7d23e8a289535041ccace8b0f0140ea12
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Allows adding additional properties to the target after the initial
call to qt_internal_add_plugin.
Change-Id: I7998c906e53699ec41b44b51aabbe480ae698b21
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Otherwise we don't create a Qt6FooPlugins.cmake file in shared Qt
builds.
Adjust comment.
Amends f68e2c92cc0ed2c1929140402c061359bc2363a5
Related to 7d6f1ee5a75cae9d122a3f0c7b3a6d03f380535e
Change-Id: I9c66d81197a4867039d5c53daf1b7edf0391c701
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The CMake build system files are properly generated, but the qmake parts
were missing.
Change-Id: Icbcce3143db976c536c802ea2314bc3f2595da51
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's perfectly possible to create static plugins in an otherwise shared
Qt build, but the logic to import these plugins into applications was
assuming a fully static Qt build. We now handle this more granularly.
This works for in-source tools and tests as well, which don't go through
the same CMake machinery for plugins as user projects do. The only case
that does not currently work is in-source examples, as they don't share
any of the plugin machinery with neither Qt internal tools/tests or user
project, but that's a bigger architectural issue that goes beyond this
change.
Change-Id: Ie00a97b02ac38ec4affadc447a3bfd0ec7d9c69a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qt_internal_add_plugin calls qt_set_target_info_properties with the
TARGET_VERSION argument and passes arg_VERSION. However, the function
qt_internal_add_plugin does not have a VERSION argument.
If arg_VERSION is set before calling qt_internal_add_plugin, that value
will be used, and that could be wrong for the plugin.
Remove the TARGET_VERSION argument from the
qt_set_target_info_properties call.
Pick-to: 6.4
Change-Id: I0ae9e0e6636d74fdc20e6ab9ca525c5a9126000c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When recording which package version to look for in
QtFooModuleDependencies.cmake and other files like it,
instead of using PROJECT_VERSION, use the version of the
package that contains the dependency.
For example if we're hypothetically building the qtdeclarative repo
from the 6.4 branch, against an installed 6.2 qtbase, then
the Qt6QmlModuleDependencies.cmake file will have a
find_package(Qt6Core 6.2) call because qtdeclarative's
find_package(Qt6Core) call found a 6.2 Core when it was configured.
This allows switching the versioning scheme of specific Qt modules
that might not want to follow the general Qt versioning scheme.
The first candidate would be QtWebEngine which might want to
follow the Chromium versioning scheme, something like
Qt 6.94.0 where 94 is the Chromium major version.
Implementation notes.
We now record the package version of a target in a property
called _qt_package_version. We do it for qt modules, plugins,
3rd party libraries, tools and the Platform target.
When we try to look up which version to write into the
QtFooModuleDependencies.cmake file (or the equivalent Plugins and
Tools file), we try to find the version
from a few sources: the property mentioned above, then the
Qt6{target}_VERSION variable, and finally PROJECT_VERSION.
In the latter case, we issue a warning because technically that should
never have to happen, and it's a bug or an unforeseen case if it does.
A few more places also need adjustments:
- package versions to look for when configuring standalone
tests and generating standalone tests Config files
- handling of tools packages
- The main Qt6 package lookup in each Dependencies.cmake files
Note that there are some requirements and consequences in case a
module wants to use a different versioning scheme like 6.94.0.
Requirements.
- The root CMakeLists.txt file needs to call find_package with a
version different from the usual PROJECT_VERSION. Ideally it
should look for a few different Qt versions which are known to be
compatible, for example the last stable and LTS versions, or just
the lowest supported Qt version, e.g. 6.2.6 or whenever this change
would land in the 6.2 branch.
- If the repository has multiple modules, some of which need to
follow the Qt versioning scheme and some not,
project(VERSION x.y.z) calls need to be carefully placed in
subdirectory scopes with appropriate version numbers, so that
qt_internal_add_module / _tool / _plugin pick up the correct
version.
Consequences.
- The .so / .dylib names will contain the new version, e.g. .so.6.94
- Linux ELF symbols will contain the new versions
- syncqt private headers will now exist under a
include/QtFoo/6.94.0/QtFoo/private folder
- pri and prl files will also contain the new version numbers
- pkg-config .pc files contain the new version numbers
- It won't be possible to write
find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code.
One would have to write find_package(Qt6WebEngineWidgets 6.94)
otherwise CMake will try to look for Qt6Config 6.94 which won't
exist.
- Similarly, a
find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call
would always find any kind of WebEngine package that is higher than
6.4, which might be 6.94, 6.95, etc.
- In the future, if we fix Qt6Config to pass EXACT to its
subcomponent find_package calls,
a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets)
would fail to find WebEngineWidgets, because its 6.94.0 version
will not be equal to 6.5.0. Currently we don't pass through EXACT,
so it's not an issue.
Augments 5ffc744b791a114a3180a425dd26e298f7399955
Task-number: QTBUG-103500
Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Output names of static libraries might be different from target names.
For example, the library name of Qt6::DeviceDiscoverySupportPrivate is
"Qt6DeviceDiscoverySupport.lib", and the library name of
Qt6::QTlsBackendCertOnlyPlugin is "qcertonlybackend.lib".
This commit make pdb files names consistent with the library names.
And make sure we have set correct OUTPUT_NAME property before calling
qt_set_common_target_properties()/qt_internal_set_compile_pdb_names().
Change-Id: Idb3cacd7a46a4f298fd584b927b5d726956faea8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
CMake has logic to rewrite build rpaths that contain
CMAKE_STAGING_PREFIX to instead point to CMAKE_INSTALL_PREFIX.
This breaks running executables from the build directory, because
their build rpath will point to a location where the libraries might
not exist yet (we didn't install Qt yet).
Work around this by setting CMAKE_STAGING_PREFIX to a fake path, so
that CMake does not do the rewriting anymore.
CMAKE_STAGING_PREFIX needs to be set at subdirectory scope, not
function scope, which is why
qt_internal_apply_staging_prefix_build_rpath_workaround() is a macro
that is called from within each Qt internal function that creates
a target.
The workaround can be disabled by configuring with
-DQT_NO_STAGING_PREFIX_BUILD_RPATH_WORKAROUND=ON
The downside of this workaround is that it breaks per-subdirectory
install rules like 'ninja src/gui/install'.
Regular global installation like 'ninja install' works fine.
This is similar to what we do for tests in
qt_set_up_fake_standalone_tests_install_prefix()
introduced by 20292250d44e08437306096e9096fc655cc9fb8b
The reason it's not as good for other target types is because in
contrast to tests, we do want to install them.
In case if someone does call `ninja src/gui/install' they will most
likely get a permission error, telling them it's not possible to
install into
/qt_fake_staging_prefix/
check_qt_internal_apply_staging_prefix_build_rpath_workaround
Fixes: QTBUG-102592
Change-Id: I6ce78dde1924a8d830ef5c62808ff674c9639d65
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This introduces a new helper function,
qt_internal_add_repo_local_defines and makes use of it in
qt_internal_add_{module,test,executable,benchmark,plugin}. That function
checks whether QT_EXTRA_INTERNAL_TARGET_DEFINES is set. If it is, the
defines listed in there will be aded to all targets passed to the
functions mentioned above.
The intended usage is that QT_EXTRA_INTERNAL_TARGET_DEFINES gets set
in the repository local .cmake.conf. This allows e.g. opting in to
source incompatible changes in leaf modules (as long as those are
guarded by some define).
Pick-to: 6.2 6.3
Fixes: QTBUG-101640
Change-Id: I06c3693ee69f46e95a48de724621f0c97e7cc3a8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When building Qt repos, all find_package(Qt6) calls request a
PROJECT_VERSION version which is set in .cmake.conf via
QT_REPO_MODULE_VERSION.
This means trying to configure qtsvg from a 6.3 branch using a
6.2 qtbase won't work, because qtsvg will call find_package(Qt6 6.3)
and no such Qt6 package version exists.
There are certain scenarios where it might be useful to try to do
that though.
One of them is doing Qt development while locally mixing branches.
Another is building a 6.4 QtWebEngine against a 6.2 Qt.
Allow to opt out of the version check by configuring each Qt repo
with -DQT_NO_PACKAGE_VERSION_CHECK=TRUE. This setting is not
recorded and will have to be set again when configuring another
repo.
The version check will also be disabled by default when configuring
with the -developer-build feature. This will be recorded and embedded
into each ConfigVersion file.
If the version check is disabled, a warning will be shown mentioning
the incompatible version of a package that was found but that package
will still be accepted.
The warning will show both when building Qt or using Qt in a user
project.
The warnings can be disabled by passing
-DQT_NO_PACKAGE_VERSION_INCOMPATIBLE_WARNING=TRUE
Furthermore when building a Qt repo, another warning will show when an
incompatible package version is detected, to suggest to the Qt builder
whether they want to use the incompatible version by disabling the
version check.
Note that there are no compatibility promises when using mixed
non-matching versions. Things might not work. These options are only
provided for convenience and their users know what they are doing.
Pick-to: 6.2
Fixes: QTBUG-96458
Change-Id: I1a42e0b2a00b73513d776d89a76102ffd9136422
Reviewed-by: Craig Scott <craig.scott@qt.io>
Previously we only created object library static plugin initializers
for Qt plugins only, not user-project plugins.
The reason was that if a user tried to install the plugin target via
an export set, CMake would error out saying that the _init library is
not part of the same export set.
Introduce an OUTPUT_TARGETS option that would allow projects to get
the name of the generated _init target, so they can install it if
needed.
This was already done for qt6_add_qml_module, so we just introduce the
same option for qt6_add_plugin.
Now user static plugins will have an _init target created, which will
be propagated to consumers whenever the consumers link against the
plugin itself.
We also need an internal option to disable this propagation, because
it's handled a bit differently for Qt plugins which can be linked
either via finalizers or via usage requirements.
Amends 91c65dd80cdd2de666448c14202c0c63718152b6
As a result of the implementation change, cleanup example projects
to ensure that they build successfully (the important part is
specifying the CLASS_NAME).
Only plugandpaint works properly with both shared and static Qt
builds.
echoplugin works with a shared Qt build, but not a static one due to
some assumptions in the C++ code about shared plugins.
styleplugin doesn't seem to work properly neither with shared Qt
builds nor static Qt builds, at least on macOS. But it builds fine.
For some reason even if the plugin is found, the style is not applied.
Amends 4caac1feea025b0ad496141e8f16ab88c04c2caa
Pick-to: 6.2
Task-number: QTBUG-80863
Task-number: QTBUG-92933
Change-Id: I6f631cda9566229b7a63992b23d7d7fa50303eeb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The logic for linking plugins in a static build in Qt6*Plugins.cmake
looks up plugins that are named Qt6*PluginConfig.cmake, and the file
name is computed by the target name.
Not naming the target 'Plugin' therefore means it won't be picked up
in static builds.
Pick-to: 6.2
Task-number: QTBUG-95731
Change-Id: Ic83a29d7c91492c302eb413a69577a0c550e1a1b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The intention is to remove TYPE as a keyword completely before 6.2.0
release, but in case if that's not possible due to the large amount
of repositories and examples, just print a deprecation warning for
now and handle both TYPE and PLUGIN_TYPE.
Task-number: QTBUG-95170
Pick-to: 6.2
Change-Id: If0c18345483b9254b0fc21120229fcc2a2fbfbf5
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
All internal libraries, plugins, object libraries (resources, plugin
initializers) need to be built with bitcode flags when targeting iOS.
Internal here means all libraries added by qt_internal_add_X
functions or associated with internal libraries.
We didn't do that for plugin initializers, which were added not too
long ago.
Extract the logic that links to Qt::PlatformModuleInternal into a
separate function to be used for object libraries.
Use it for resources and plugin initializers. It will also be used
in qtdeclarative for qml plugin initializers.
Pick-to: 6.2
Task-number: QTBUG-95208
Change-Id: I366996078f5e9d1c2d2797f6b81c522ee99529e3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Both the compiler and linker -fapplication-extension flag should only
be applied when building Qt's libraries (not executables).
It's up to the user project whether their code will be restricted with
application-extension-only APIs.
In qmake that can be achieved by adding to the qmake project
CONFIG += app_extension_api_only
In CMake it can be achieved by either adding the compiler and link flags
in the project directly (using target_X_options) or by setting the
appropriate setting in the Xcode project when using the Xcode
generator.
Amends e189126f1ae1d2fa2ad0f95ee2c4aa72c770a97b
Pick-to: 6.2
Task-number: QTBUG-95199
Change-Id: Ie7a764d460a89c7650391abff0fcc5abfcabef64
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Repositories have been changed to be free of this warning. We're now
changing the default of QT_WARN_PLUGIN_PUBLIC_KEYWORDS to ON.
Set this variable to OFF to disable the warnings.
Pick-to: 6.2
Change-Id: Ie37a4df1032f5b1e9152d970e8a14c574ed70241
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We didn't do it in Qt 5 times and it was accidentally done for Qt 6.
There's no reason to generate them, the .pri files are only meant to
be used for regular plugins so a project can do QTPLUGINS += foo.
That mechanism is not needed for qml plugins which use
qmlimportscanner instead.
Furthermore the pri contents didn't contain a class name, so they
couldn't be used anyway.
Pick-to: 6.2
Change-Id: I6299fda21ece0f693a817ab558b45aa46b97e5ee
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
