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
Change-Id: I86197d62bfac96f9c142d8abfe85c9b6f6f1a527
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit aef789ad97ee9b8f3254a0e315a0d8a4785bcbf7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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>
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
Change-Id: I89242307438576a0cbb3cdca80a9cb72818b6035
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit c7027880aa746a01362ac12491910479d7fc67e3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
[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.
Task-number: QTBUG-87776
Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit ad7b94e163ac5c3959a7e38d7f48536be288a187)
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>
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.
Task-number: QTBUG-87776
Change-Id: I08a48954576dc3c0b6fde809f90d2022201d7eb0
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 2d38af3125d18255007f7451f31e26e9c16af45a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
[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
Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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>
Follow the same patterns as for qpa and rhi. Semi-public APIs will be
put under the "namespace" ssg which is short for Spatial Scene Graph.
Taks-number: QTBUG-116570
Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
If source or build directry contain '3rdparty' in their path, all
header files are marked as 3rdparty and will never be installed.
This commit is CMake counterpart of
ea4a3d78a776e10955caf6cf9b1054ddb50f40d3
Amends ea4a3d78a776e10955caf6cf9b1054ddb50f40d3
Fixes: QTBUG-116137
Pick-to: 6.5 6.6
Change-Id: Ib93fb879867e3aeb6e44193c4253e73173c141d2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Currently QT_USE_QSTRINGBUILDER is added for all Qt module targets by
default, and it's not possible to remove this definition.
Replace this definition with the generator expression that is
propagated by the PlatformModuleInternal target.
Change-Id: I1c606e16809dc720e2eb72191e1670dfc48f1b48
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>
We should sync external headers for 3rdpary projects
like freetype and harfbuzz-ng and keep the directory
structure.
Fixes: QTBUG-113416
Pick-to: 6.6 6.5
Change-Id: Ie66edb9a21cff37ca6c8c68b6d225de6d8bbad81
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
This reverts commit 389507a047e0ec0721535052df6ddf957fbb95b3.
Reason for revert: The original patch unintentionally changes
the deprecation warning behavior for user projects. Merging
the current change will resurface the original static qt build
bug until a new fix is developed.
Pick-to: 6.6
Change-Id: I29b41b43fdd76b19bc46439470e04443dc2b8ddb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Yuhang Zhao <yuhangzhao@deepin.org>
Currently some libraries created by Qt are lacking some compile
definitions and compile options, and this issue is causing us
troubles when building Qt statically. This patch tries to reduce
the parameter difference when compiling Qt's own libraries.
Change-Id: I3842943a874fab32ef90980e8aa29f5beb01feeb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from
shadertools; done separately) become "RHI APIs", following the concept
of QPA APIs.
Mirror completely what is done for QPA headers, but using the "rhi"
prefix for the headers. This involves updating syncqt to handle the
new category of headers. (a note on the regex: matching everything
starting with "qrhi" is not acceptable due to incorrectly matching
existing and future headers, hence specifying the four header names
explicitly)
There is going to be one difference to QPA: the documentation for
everything RHI is going to be public and part of the regular docs, not
hidden with \internal.
In addition to the header renaming and adding the comments and
documentation notes and warnings, there is one significant change
here: there is no longer a need to do API-specific includes, such as
qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a
single header that is then included from qrhi.h. This means that users
within Qt, and any future applications can just do #include
<rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no
other headers are needed.
There are no changes to functionality in this patch. Only the
documentation is expanded, quite a lot, to eliminate all qdoc warnings
and make the generated API docs complete. An example, with a quite
extensive doc page is added as well.
Task-number: QTBUG-113331
Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
CMake doesn't resolve REALPATH for the non-existing files.
This limitation blocks the use of REALPATH when collecting the
generated module header files. The real path should be resolved
by syncqt implicitly and CMake scripts should rely on ABSOLUTE paths
only, which should be consistent for any files including the generated
files.
Task-number: QTBUG-113295
Pick-to: 6.5
Change-Id: I0219c7bf34ef6a6589c6d5fade4c2ed3f8036ef0
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
The module information .json gained a "plugin_types" key in 6.5.0.
Unfortunately, this contained the "sanitized" version of plugin types,
meaning dashes converted to underscores. For plugin types that contain
dashes, e.g. wayland-decoration-client, the file contained
wayland_decoration_client, which doesn't match its plugin directory
name.
Since "unsanitizing" plugin names is hard and "sanitizing" is easy, we
now store the unsanitized plugin names and burden the consumer of the
module .json files with the sanitation task.
[ChangeLog][CMake] The module information JSON files now contain the
unsanitized plugin types of a module, e.g. wayland-decoration-client
instead of wayland_decoration_client. Consumers of the module
information file must sanitize plugin types themselves if necessary.
Pick-to: 6.5
Fixes: QTBUG-112872
Change-Id: I09cc9406b360779087086707abee3d5219a24452
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
Add CMake rules to skip syncing and installation of header files
that are recognized as non-module. Previously these rules were in
syncqt.cpp only and CMake ignored them when creating the installation
rules. Now we skip any post processing for the header files that:
- are public and located in the '3rdparty' directory unless the module
is the 3rdparty one
- are not a part of the module source tree unless they are generated
- have the _qt_non_module_header property set to TRUE
Pick-to: 6.5
Change-Id: I045cfc2b8074f0c086c975aae95f14845e3edfef
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If Qt was configure with QT_NAMESPACE set, store that in the module
information files under 'built_with.namespace'.
Task-number: QTBUG-111158
Change-Id: I273309cb263c64f801dbb7238440336d7afa635e
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
