This change adds a new -sbom configure option to allow generating and
installing an SPDX v2.3 SBOM file when building a qt repo.
The -sbom-dir option can be used to configure the location where
each repo sbom file will be installed.
By default it is installed into
$prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx
which is basically ~/Qt/sbom/qtbase-6.8.0.spdx
The file is installed as part of the default installation rules, but
it can also be installed manually using the "sbom" installation
component, or "sbom_$lower_project_name" in a top-level build. For
example: cmake install . --component sbom_qtbase
CMake 3.19+ is needed to read the qt_attribution.json files for
copyrights, license info, etc. When using an older cmake version,
configuration will error out. It is possible to opt into using an
older cmake version, but the generated sbom will lack all the
attribution file information.
Using an older cmake version is untested and not officially supported.
Implementation notes.
The bulk of the implementation is split into 4 new files:
- QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing
and dispatching the generation of various pieces of the SBOM document
e.g. a SDPX package associated with a target like Core, a SDPX
file entry for each target binary file (per-config shared library,
archive, executable, etc)
- QtPublicSbomGenerationHelpers.cmake - for non-Qt specific
implementation of SPDX generation. This also has some code that was
taken from the cmake-sbom 3rd party project, so it is dual licensed
under the usual Qt build system BSD license, as well as the MIT
license of the 3rd party project
- QtPublicGitHelpers.cmake - for git related features, mainly to embed
queried hashes or tags into version strings, is dual-licensed for
the same reasons as QtPublicSbomGenerationHelpers.cmake
- QtSbomHelpers.cmake - Qt-specific functions that just forward
arguments to the public functions. These are meant to be used in our
Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones
for naming consistency. These function would mostly be used to
annotate 3rd party libraries with sbom info and to add sbom info
for unusual target setups (like the Bootstrap library), because most
of the handling is already done automatically via
qt_internal_add_module/plugin/etc.
The files are put into Public cmake files, with the future hope of
making this available to user projects in some capacity.
The distinction of Qt-specific and non-Qt specific code might blur a
bit, and thus the separation across files might not always be
consistent, but it was best effort.
The main purpose of the code is to collect various information about
targets and their relationships and generate equivalent SPDX info.
Collection is currently done for the following targets: Qt modules,
plugins, apps, tools, system libraries, bundled 3rd party libraries
and partial 3rd party sources compiled directly as part of Qt targets.
Each target has an equivalent SPDX package generated with information
like version, license, copyright, CPE (common vulnerability
identifier), files that belong to the package, and relationships on
other SPDX packages (associated cmake targets), mostly gathered from
direct linking dependencies.
Each package might also contain files, e.g. libQt6Core.so for the Core
target. Each file also has info like license id, copyrights, but also
the list of source files that were used to generate the file and a
sha1 checksum.
SPDX documents can also refer to packages in other SPDX documents, and
those are referred to via external document references. This is the
case when building qtdeclarative and we refer to Core.
For qt provided targets, we have complete information regarding
licenses, and copyrights.
For bundled 3rd party libraries, we should also have most information,
which is usually parsed from the
src/3rdparty/libfoo/qt_attribution.json files.
If there are multiple attribution files, or if the files have multiple
entries, we create a separate SBOM package for each of those entries,
because each might have a separate copyright or version, and an sbom
package can have only one version (although many copyrights).
For system libraries we usually lack the information because we don't
have attribution files for Find scripts. So the info needs to be
manually annotated via arguments to the sbom function calls, or the
FindFoo.cmake scripts expose that information in some form and we
can query it.
There are also corner cases like 3rdparty sources being directly
included in a Qt library, like the m4dc files for Gui, or PCRE2 for
Bootstrap.
Or QtWebEngine libraries (either Qt bundled or Chromium bundled or
system libraries) which get linked in by GN instead of CMake, so there
are no direct targets for them.
The information for these need to be annotated manually as well.
There is also a distinction to be made for static Qt builds (or any
static Qt library in a shared build), where the system libraries found
during the Qt build might not be the same that are linked into the
final user application or library.
The actual generation of the SBOM is done by file(GENERATE)-ing one
.cmake file for each target, file, external ref, etc, which will be
included in a top-level cmake script.
The top-level cmake script will run through each included file, to
append to a "staging" spdx file, which will then be used in a
configure_file() call to replace some final
variables, like embedding a file checksum.
There are install rules to generate a complete SBOM during
installation, and an optional 'sbom' custom target that allows
building an incomplete SBOM during the build step.
The build target is just for convenience and faster development
iteration time. It is incomplete because it is missing the installed
file SHA1 checksums and the document verification code (the sha1 of
all sha1s). We can't compute those during the build before the files
are actually installed.
A complete SBOM can only be achieved at installation time. The install
script will include all the generated helper files, but also set some
additional variables to ensure checksumming happens, and also handle
multi-config installation, among other small things.
For multi-config builds, CMake doesn't offer a way to run code after
all configs are installed, because they might not always be installed,
someone might choose to install just Release.
To handle that, we rely on ninja installing each config sequentially
(because ninja places the install rules into the 'console' pool which
runs one task at a time).
For each installed config we create a config-specific marker file.
Once all marker files are present, whichever config ends up being
installed as the last one, we run the sbom generation once, and then
delete all marker files.
There are a few internal variables that can be set during
configuration to enable various checks (and other features) on the
generated spdx files:
- QT_INTERNAL_SBOM_VERIFY
- QT_INTERNAL_SBOM_AUDIT
- QT_INTERNAL_SBOM_AUDIT_NO_ERROR
- QT_INTERNAL_SBOM_GENERATE_JSON
- QT_INTERNAL_SBOM_SHOW_TABLE
- QT_INTERNAL_SBOM_DEFAULT_CHECKS
These use 3rd party python tools, so they are not enabled by default.
If enabled, they run at installation time after the sbom is installed.
We will hopefully enable them in CI.
Overall, the code is still a bit messy in a few places, due to time
constraints, but can be improved later.
Some possible TODOs for the future:
- Do we need to handle 3rd party libs linked into a Qt static library
in a Qt shared build, where the Qt static lib is not installed, but
linked into a Qt shared library, somehow specially?
We can record a package for it, but we can't
create a spdx file record for it (and associated source
relationships) because we don't install the file, and spdx requires
the file to be installed and checksummed. Perhaps we can consider
adding some free-form text snippet to the package itself?
- Do we want to add parsing of .cpp source files for Copyrights, to
embed them into the packages? This will likely slow down
configuration quite a bit.
- Currently sbom info attached to WrapFoo packages in one repo is
not exported / available in other repos. E.g. If we annotate
WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be
available when looking up WrapZLIB in qtimageformats.
This is because they are IMPORTED libraries, and are not
exported. We might want to record this info in the future.
[ChangeLog][Build System] A new -sbom configure option can be used
to generate and install a SPDX SBOM (Software Bill of Materials) file
for each built Qt repository.
Task-number: QTBUG-122899
Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 37a5e001277db9e1392a242171ab2b88cb6c3049)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The QtFindWrapHelper.cmake file retrieves the version of the
underlying system package version or bundled package version, and
passes that to find_package_handle_standard_args to show which version
was found.
But it did not set a ${PACKAGE_NAME}_VERSION variable, which means
we didn't record the version in qt_find_package, and thus in the final
SBOM.
Make sure we set the variable.
Amends 7ad8c347feb5e336c3833d6d3ac021a0a14b714a
Change-Id: Ia0d5b895de36017949e6607d17093459dca302b3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 0be79f14865c0a19fde0abad7d1722f0bac3b7c2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Use the variable name but not the unwrapped value.
Pick-to: 6.7 6.5
Change-Id: Ie392a4875fe412b8eb273a457a83cd08cd9f5e15
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit e960fb136e77437e158367f86bc926504e0fdab6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The behavior that argument was enabling is the default one now.
Task-number: QTBUG-90492
Change-Id: I11711d4c794f0b22169abb595b8ffad2eeb1300d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 1ef3bd05eb45d53cdcf92b933603b995283b3432)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Consider a feature that has ENABLE and CONDITION expressions. For
example, system-libb2 on a Linux machine that does not have the
libb2-dev package installed:
qt_feature("system-libb2" PRIVATE
LABEL "Using system libb2"
CONDITION Libb2_FOUND
ENABLE INPUT_libb2 STREQUAL 'system'
DISABLE INPUT_libb2 STREQUAL 'no' OR INPUT_libb2 STREQUAL 'qt'
)
If the feature is enabled by the user by setting
FEATURE_system_libb2=ON, then there's an error:
Feature "system_libb2": Forcing to "ON" breaks its condition...
This is expected.
If the feature is enabled by the user by triggering the ENABLE condition
via the -system-libb2 configure flag (that sets INPUT_libb2 to
"system"), we did not get an error message.
This was unexpected and inconsistent.
Now, we consider features that are enabled via their ENABLE condition as
set by the user and yield an error if the CONDITION doesn't match.
Fixes: QTBUG-126144
Change-Id: I249baf9ab4f434f5a96894f4ec055f70859ffca9
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit ad227368c3ab3a9dc68208bce2d075edefe7e6e0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
If the forward argument was meant to be 0, it was not forwarded
because it evaluated to false in if(condition).
To pass it along, instead check for empty strings.
Change-Id: Ia366df147de0c2d333017da43dc0643b56a89e9c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 96abceb64e5dc0570ca7c3419f401cfafe946ba0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
If a build dir is removed using rm -r *, this still leaves
dot files around, specifically the .ninja_log file.
Because of a possibly unspecified behavior of listing directories as
OUTPUTs in a add_custom_command call for the
${target}_copy_fw_sync_headers custom target, we end up with a
situation where the custom command is not rerun by ninja because the
directory OUTPUT was encountered in the .ninja_log file.
Make sure to specify an additional file as an OUTPUT, to ensure the
command does rerun, and thus copies all headers from the syncqt
staging directory.
Amends 103eca1070
Pick-to: 6.7 6.5
Fixes: QTBUG-126056
Change-Id: I5664cf074158199e0c7fd5e312ecf739133d7f2e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit c561bcceed0300a14e2062958afce62776be4b6f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Due to QTBUG-125371 we currently record Qt6 as a third party
dependency for many qt packages.
Until that is fixed, we should not record the provided targets of the
Qt6 package, because it causes issues during SBOM generation.
Amends 58eefbd0b6
Task-number: QTBUG-125371
Change-Id: I35d548996c3820aaa7a1175b3a1f34c23ec2290f
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
It's a helper to pass along option arguments that are set by
cmake_parse_arguments, from the current scope to another function
call.
It avoids a lot
if(arg_FOO) set(options FOO ${arg_FOO})
boilerplate.
It is somewhat the opposite of _qt_internal_remove_args.
The options that the function takes are prefixed with FORWARD_
to avoid possible naming conflicts with the actual options that should
be forwarded.
Change-Id: I54fd22b884d8af8379f2f735eb911a3bc66d3416
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Each qt_find_package can specify a PROVIDED_TARGETS option, to inform
which targets will be created by that package.
The call then saves the package name, version, etc on each of the
provided targets.
Currently the provided targets info is not persisted anywhere after
configuration ends.
We will need this for SBOM creation, so that we can collect
information about such dependencies when configuring leaf
repos, where find_dependency calls are implicit, and don't contain
the PROVIDED_TARGETS option, and we need to go from package name to
target name (and any recorded info it the target has).
This is especially relevant for static library builds, where private
dependencies become public dependencies.
Collect the provided targets information at post process time and
persist it for each 'package name + components requested' combination
into the Dependencies.cmake file.
This information will be used in a later change for SBOM generation.
Change-Id: I1693f81b1ad3beaf9b02e44b09a5e977923f0d85
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The QtFindWrapHelper include used in FindWrap scripts can choose to
call find_package() on one of two packages. The packages might set a
VERSION variable. We should set the same version for the FindWrap
package as well.
There are two sources where the version will be queried from. First
from the underlying ${package_name}_VERSION variable.
And if that is empty, from a property that is set by qt_find_package()
The former might be empty because find_package might be called from
a function instead of a macro, which is the case for any find_package
call in configure.cmake files that get loaded by the
qt_feature_evaluate_features function.
Thus we need the indirection via the property that qt_find_package
will set.
Change-Id: I57fd818cb9dedf5e27a6d805e3d817d8d18be36d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Encapsulate the boilerplate logic of querying a property and setting
it to an empty string instead of NOTFOUND, before appending a value,
removing duplicates and assigning the values back to the property.
Change-Id: I7aefd11e9bdd77090324ec50c682d62181d22076
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Move the implementations into QtPublicCMakeHelpers and just forward
to those public implementations in the old code.
The new public api will be used in the public sbom cmake files.
Change-Id: I979319935611e3f553ebd414f8304f1a3163c4ee
Reviewed-by: Alexey Edelev <alexey.edelev@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>
Because the configs passed to the ALL_CMAKE_CONFIGS option were quoted
cmake_parse_arguments(PARSE_ARGV) would escape the semicolon in
the set value, effectively doing
set(arg_ALL_CMAKE_CONFIGS "Release\;Debug")
Then the
list(GET arg_ALL_CMAKE_CONFIGS 0 first_config)
call would essentially do
set(first_config "Release;Debug")
and the
if(all_configs_count GREATER 1
AND NOT arg_CMAKE_CONFIG STREQUAL first_config)
condition would never trigger because a single config string can never
equal a double config string.
Remove the quotes to ensure correct behavior.
This won't really trigger any behavior change, because we exclude
installation of Debug executables in -debug-and-release builds,
but it will make --trace-expand logs less confusing.
Amends f240d94f14
Pick-to: 6.7
Change-Id: I53179511c7698c90b33cb3ff2762cef680a99815
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
To allow using Android 14 APIs, this affects only Java
code.
Amends 7b84cd62b0.
Change-Id: Ie79df773499976ba5c847be98ff5d21ee55036e9
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Recent zstd versions provide the libstd target but not only libzstd_shared
or libzstd_static. Attempt to use it as the WrapZSTD::WrapZSTD counterpart
if the target exists.
Task-number: QTBUG-119469
Change-Id: I47916bfa6f10883d099184a497800277c8026b14
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
There was a stray '}' character in the value.
Amends 8f03bb6bd8
Change-Id: I06f9200b1449bc54ec07ace1336bb97a8f132158
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Bump the minimum supported Android API from 23 to 28 i.e.
Android Oreo 9. This is done to focus more and more on
recent versions.
Fixes: QTBUG-125023
Task-number: QTBUG-124890
Change-Id: I4d510b771f413e5711dd44de454211e019c63db6
Reviewed-by: Heikki Halmet <heikki.halmet@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>
This will be used by the SBOM generation code to retrieve the
directory where the framework file is installed.
Change-Id: I882344f1fa3c5a77e3cce85d2044aa0e682bed40
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
There was refactoring in 8c41125118 to
handle custom postfixes, which caused a regression in the postfix not
being set for macOS frameworks.
Specifically we set CMAKE_FRAMEWORK_MULTI_CONFIG_POSTFIX_DEBUG to
the value of ${${postfix_var}} but that variable was empty, because we
only set it in the PARENT_SCOPE.
Set the variable also in the current scope.
Amends 8c41125118
Pick-to: 6.5 6.7
Change-Id: Iae3f1050bb11805b4cce01ec491a13a3d6c0a9fc
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This requires some fixes in several classes that are also included
in this patch.
The QTestEvent hierarchy is all-inline and changes layout depending on
QT_GUI_LIB and QT_WIDGETS_LIB, so we can't just export it. Suppress the
warning in that header for now. Created QTBUG-104486 to track a fix for
the real issue.
The QFutureInterface hierarchy is also all-inline, but templates, so
doesn't trigger, except the <void> specialization. Created
QTBUG-125115 to track a fix for the real issue.
Done-with: Marc Mutz <marc.mutz@qt.io>
Task-number: QTBUG-45582
Change-Id: I96b3e109aa989b70e0d4809b90bd53a369e50d55
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It can happen that we are not able to determine which
Emscripten version Qt is built with, for example if
the detection code runs at a time when qconfig.h has
not been created yet.
In that case skip printing a warning since we are not
able to offer a sensible recommendation.
This fixes Qt configure when building for shared libraries,
where we would previously print this warning several
times:
Qt Wasm built with Emscripten version:
You are using Emscripten version: 3.1.50
The recommended version of Emscripten for this Qt is: 3.1.50
This may not work correctly
Change-Id: Ie15300e89c0e4b6f22650e662dd30fd32828e60c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Builtin testdata packages all test files into resources. This is used
on mobile platforms by default, but it can be useful on other platforms
as well. Add CMake option to force this on other platforms.
Change-Id: I67c82bc735960be53b351ed16526cbfacfbe9bb6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Parse the -qpa configure argument as list and translate it to the
QT_QPA_PLATFORMS cmake variable. This variable is new to the Qt build
procedure. The QT_QPA_DEFAULT_PLATFORM variable supposed to get
multiple values, but this didn't work at all, since the variable value
then was used in the compile definition that is expected to be a single
value QPA platfrom definition. This inconsistency forced to introduce
a new variable.
The QT_QPA_DEFAULT_PLATFORM variable now controls the first-choice QPA
plugin for the GUI applications. The new configure argument
-default-qpa is now translated to the QT_QPA_DEFAULT_PLATFORM variable
instead the of -qpa one. The -qpa configure argument is now translated
to the QT_QPA_PLATFORMS variable, which is new one as well. The
variable contains the list of QPA plugins that are "default" for this
Qt configuration. The meaning of the "default" plugins is related to
the DEFAULT_IF argument of qt_internal_add_plugin command. Plugins
that are listed in the QT_QPA_PLATFORMS variable will be treated as
default by the build system and will be deployed within user
applications when using deployment API or linked statically when using
static Qt.
The QT_QPA_DEFAULT_PLATFORM falls back to the QT_QPA_PLATFORMS first
value in the list if it's not set explicitly and either
'-DQT_QPA_PLATFORMS' or '-qpa' arguments are specified.
[ChangeLog][CMake] Added QT_QPA_PLATFORMS variable which controls the
list of QPA plugins that will be deployed within the applications by
default.
[ChangeLog][CMake] The '-qpa' configure argument now is mapped to the
QT_QPA_PLATFORMS variable and has different functionality. It doesn't
control the platform plugin that the GUI application is using by
default, but controls the list of QPA plugins that will be deployed
within the applications by default.
[ChangeLog][CMake] Added '-default-qpa' argument which replaces the
'-qpa' one. The argument is translated to the QT_DEFAULT_QPA_PLATFORM
CMake variable and selects the default platform that should be used
by GUI application if QT_QPA_PLATFORM environment variable is not set.
Task-number: QTBUG-124265
Task-number: QTBUG-87805
Task-number: QTBUG-124449
Change-Id: Ibcebaccc535aaed6374f15ccfeddb3e6128f5ce0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Some of our FindWrap scripts try to call find_package() once or more
to find a system package, and then fallback to a different source in
case if not found.
The side effect of this is that find_package() will append not found
packages to the global PACKAGES_NOT_FOUND property.
FeatureSummary feature_summary() will then list these as not found,
creating confusion.
For example while FindWrapSystemPCRE2 might be found, PCRE2 found will
be shown as not found, because we found the package via PkgConfig
instead of cmake Config file.
Manually remove these packages from the PACKAGES_NOT_FOUND property
in some of our Find scripts, to avoid the confusion.
Pick-to: 6.7
Fixes: QTBUG-96120
Task-number: QTBUG-96394
Task-number: QTBUG-111216
Change-Id: I4be825c810248202c34f446e3cebe66574d0531c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The QNativeInterface::QVisionOSApplication interface allows opening
and dismissing an immersive space, as well as registering a compositor
layer implementation that can be used to configure the compositor
layer and render to it with Metal.
The compositor layer implementation is consulted both for immersive
spaces triggered explicitly, and when the default scene of the app
is set to CPSceneSessionRoleImmersiveSpaceApplication via the
UIApplicationPreferredDefaultSceneSessionRole in the Info.plist.
All of this requires that the application follows the SwiftUI app
lifecyle, so our application entrypoint is now a SwiftUI app. The
existing qt_main_wrapper used for the QIOSEventDispatcher handles
this transparently, so there is no change for the user, who will
still receive a callback to main() when the Swift app is ready
to build its UI hierarchy.
Change-Id: Ic295010d714e90cd4d3f66bd90f321438659f3a6
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Applications not necessarly link QtGui module in
qt_internal_add_executable. They still may add link it in followoup
qt_internal_extend_target calls. We should consider this when adding
dependencies on qpa_default_plugins to the internal executables.
Pick-to: 6.7
Change-Id: Icc413bd35b631b3a356e4033faab4e6c01b29a60
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QtGui module can be linked using both versioned and non versioned
targets. Consider this when adding the dependencies to the
qpa_default_plugins targets.
Pick-to: 6.7
Change-Id: Iccbf3009ab8a4f9df4de1677f1b41445814c8c9e
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>
Change the way we collect dependencies in __qt_internal_walk_libs.
Prefer the versioned Qt targets over the namespaceless. This fixes the
generating of the pkg-config configs.
Pick-to: 6.5 6.6 6.7
Task-number: QTBUG-124135
Change-Id: I660376e122a99b5bc0874f2bc6ccd4d80c9ad453
Reviewed-by: Ionen Wolkens <ionen@gentoo.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Since Qt targets now are linked as versioned targets by default, we
should adjust the respective check in __qt_internal_walk_libs.
Pick-to: 6.7
Change-Id: Idb896c1d9eda944a06d57b0491686cd78e010df0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Dependencies that alredy start with QT_CMAKE_EXPORT_NAMESPACE shouldn't
be skipped but collected as is when generating pkg-config files.
Pick-to: 6.5 6.6 6.7
Fixes: QTBUG-124135
Change-Id: I6875337c2e1d98f657e52a5fc2c37eebccf08b98
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
qpagesize.h violated it, resulting in a bug report, so add it to headerscheck.
Task-number: QTBUG-115583
Change-Id: I4c52fb72667edd3f3cf563b8bad91d343ac95328
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We never properly handled double-hyphen arguments like --list-features.
However --developer-build worked by accident, because it did set
INPUT_developer_build implicitly.
Now, we don't automagically translate INPUT_foo to FEATURE_foo anymore,
and --developer-build stopped working.
Fix this by consistently handling -foo and --foo arguments.
Change-Id: Ibf32979b419c28e0a8e1f810f03ae3f295b14c69
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
QT_EDITION is not used anywhere in Qt6, stop
adding it to qconfig.pri.
Packaging currently unnecessarily patches
the edition when handling the first steps after
integration and again during install time.
Pick-to: 6.7 6.5 6.2
Change-Id: I0ad1933ec8fea741796fdf6d13f627a657aac401
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Iikka Eklund <iikka.eklund@qt.io>
Some repos have licenseRule.json files. Adding them to the IDE projects.
Pick-to: 6.7
Change-Id: I7fdc054d244d48e3343866775671d8f4f4c9390b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Lucie Gerard <lucie.gerard@qt.io>
The classic linker (triggered via -ld_classic) doesn't support this flag,
and we can't construct a genex that takes this into account, so add an
opt-out for Qt WebEngine.
Pick-to: 6.7
Change-Id: I62418e0ff37fe8f5bdda2fa8d01b36a8fd44542a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Qt already runs on Vision Pro as "Designed for iPad", using Qt
for iOS. This change enables building Qt for visionOS directly,
which opens the door to visionOS specific APIs and use-cases
such as volumes and immersive spaces.
The platform removes some APIs we depend on, notably UIScreen,
so some code paths have been disabled or mocked to get something
up and running.
As our current window management approach on UIKit platforms
depends on UIWindow and UIScreen there is currently no way to
bring up QWindows. This will improve once we refactor our
window management to use window scenes.
To configure for visionOS, pass -platform macx-visionos-clang,
and optionally add -sdk xrsimulator to build for the simulator.
Change-Id: I4eda55fc3fd06e12d30a188928487cf68940ee07
Reviewed-by: Alexey Edelev <alexey.edelev@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>
We are selecting a subset of the tests for batching/CI,
however this is done for the WASM configuration which
interferes with non-batched tests.
- we can only build and run tests which are in the
batching subset
- we are enabling threading tests which breaks the
no-thread configuration.
Add QT_BUILD_WASM_BATCHED_TESTS and enable for WASM and
batching. There's then no restrictions on which tests
can be selected for CI.
Change-Id: I59a67b63e80cd00676cb28f916951d2a52b0ee2c
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Not all tests have targets that we can attach the BLACKLIST files to.
Pick-to: 6.7
Change-Id: Ie0a2d72859877a8803802a4f7dc996944f002656
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Tests can be blacklisted via BLACKLIST files. This patch adds these
files to the generated IDE projects automatically when available.
Pick-to: 6.7
Change-Id: Icef2c397ada823e7b1c380dbb224694f059891ff
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Separate config.tests, coin, cmake, licenses and changelogs into
independent targets to keep the IDE projects more organized.
Pick-to: 6.7
Change-Id: Ie33d45799621c2d7ec6f022ffcfac132ac4c7b94
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Lots of files in the repos are not included into the generated IDE
projects. Therefore we add utility targets (custom targets), which are
populated by glob patterns, which should fit most files that are found
in qt's subprojects.
Pick-to: 6.7
Change-Id: I1b731e65f8db319d3cec817eea5c23a1eeaefb22
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
PACKAGE_PREFIX_PATH is not defined in cmake versions 3.29.x.
We should avoid referring the internal CMake variables.
Use the calculated reverse relative path to the prefix path
instead.
Fixes: QTBUG-124186
Pick-to: 6.5 6.6 6.7
Change-Id: Iefae132e61a3f8e8f5525c0abd6a2d41631c2fb0
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Alexandru Croitor
Alexey Edelev
Joerg Bornemann
Lucie Gérard
Assam Boudjelthia
Jesus Fernandez
Morten Sørvig
Samuli Piippo
Tor Arne Vestbø
Marc Mutz
Antti Kokko
Tim Blechmann