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>
Add the dummy check if the variable is defined to suppress the warning.
Pick-to: 6.7
Change-Id: If3bb0ef6a2587693c0ec898ceb3080ebfc1e82a7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The Qt CMake routines for generating pkg-config files don't
handle all sorts of generator expressions, see
qt_internal_set_pkg_config_cpp_flags in QtPkgConfigHelpers.cmake
which hardcodes handling of some specific expressions. In this
case, they don't handle the semicolon within the generator
expression expansion.
For the UNICODE and _UNICODE defines, this means that the pkg-config
file ends up containing "-D_UNICODE>" with the trailing ">". (The
pkg-config generator tries to parse out the generator expressions,
but the semicolon gets handled as a higher level separator, leaving
the closing bracket ">" behind.)
This issue only shows up for mingw targets, because pkg-config files
aren't generated in MSVC style builds.
Escape the semicolon as $<SEMICOLON> to make it not break the
surrounding generator expression, as parsed by the pkg-config file
generator.
The generator expressions aren't fully correctly evaluated for the
pkg-config files though; the UNICODE and _UNICODE defines don't
end up in the resulting pkg-config file even though they're used
during compilation (both before and after this change).
Fixes: QTBUG-103019
Co-authored-by: Martin Reboredo <yakoyoku@gmail.com>
Pick-to: 6.7 6.5 6.2
Change-Id: Icdb380e3b42be2a47372a8ee2b61378a33c685f7
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Li Xinwei <1326710505@qq.com>
The flags are not valid for e.g. Swift
Pick-to: 6.7
Change-Id: Ie5b46dc9147d8c024e7e27712c7b8632abd727d9
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We can't make the choice of whether to enable no_warn_duplicate_libraries
or not based on the Xcode version Qt was built with, as the target flags
will propagate to our cmake integration tests, which we run on platforms
where we don't have Xcode 15.
Pick-to: 6.7
Change-Id: I241a950a3d2e70652a3a6386e5dd86c681d1c13f
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Reviewed-by: Orkun Tokdemir <orkun.tokdemir@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>
Inline namespaces serve the purpose for which the original
-qtnamespace option was added and allow for macro simplification (no
need for any using directives). This makes it possible to use
namespaced builds of Qt also for Qt for Python and similar use cases
which have issues with the additional namespace.
[ChangeLog][QtCore] It is now possible to use an inline namespace for
-qtnamespace (option -qtinlinenamespace).
Task-number: PYSIDE-2590
Change-Id: Ia0cecf041321933a2e02d1fd8ae0e9cda699cd1e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
CMake will transform the CMAKE_OSX_SYSROOT into a path as part of
Darwin-initialize.cmake, as non-Xcode generators rely on it to
be a path when setting -isysroot.
When propagating the CMAKE_OSX_SYSROOT to consumers of Qt, we need
to propagate it by its original SDK name, so that CMake's Xcode
generator can write it by name into the SDKROOT Xcode setting by
name, and so that we don't lock the user into using the exact
same SDK path (and version) as we did when building Qt.
The QT_APPLE_SDK code path has been removed, as setting QT_APPLE_SDK
will always set the CMAKE_OSX_SYSROOT as well.
Change-Id: Ib1ef19b9dc375dddf76a2629ee790990c0722f75
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Alexandru Croitor
Lucie Gérard
Assam Boudjelthia
Alexey Edelev
Jesus Fernandez
Morten Sørvig
Samuli Piippo
Tor Arne Vestbø
Marc Mutz
Joerg Bornemann
Antti Kokko
Tim Blechmann
Martin Storsjö
Friedemann Kleint