The test run is wrapped with a special TESTRUNNER script that ignores
failing tests (there are several tests failing when built with ASAN) and
also ignores LSAN errors (memory leaks - but still visible in the
output).
The test run only fails if a test reports ASAN errors or if it
crashes (or times out, which is like a crash caused by qtestlib's
watchdog timer).
Fixes: QTQAINFRA-5025
Change-Id: I861756ab49388ac4a52409d3a780684244e469b1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Added a small helper function that also installs the script to
prefix builds. Additionally, leveraging the cmake option
CROSSCOMPILING_EMULATOR for the testrunner fits neatly in the rest
of our cmake code.
Change-Id: I75288e97c81b250ac3997f2e7a22bc7bd82b7b69
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
So we can see the command line invocations of the built cmake
auto tests.
To achieve that, we create a ninja shell script wrapper, because
ctest --build-and-test does not currently allow specifying custom
build tool options.
Details at
https://gitlab.kitware.com/cmake/cmake/-/issues/22443
Pick-to: 6.2 6.3
Change-Id: I7fb3b7f7f802943a7013c859b2cf39842a34e2e4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Add a python script that allows us to run wasm tests in CI, along with
the necessary cmake logic to install the script and execute tests
accordingly.
Change-Id: I93b95c115538c4e27b2b833405acab8162be2a8a
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
MinGW 11.2.0 comes with a strip.exe that strips the ".gnu_debuglink"
section in binaries, a section that is needed for the separate debug
information feature.
binutils version 2.34 mentions the feature for the first time:
https://sourceware.org/binutils/docs-2.34/binutils/strip.html#strip
To ensure the debuglink section is preserved, generate a shell wrapper
that calls the original strip binary with an extra option to keep the
required section.
To determine if the option is supported, we build a real shared library
on which strip will be called with the --keep-section option.
If the option is not supported, a wrapper is not generated and the
stock strip binary is used.
This logic only applies when targeting Linux and MinGW + a shared
library Qt. For other targets, the stock strip binary is used.
Developers can opt out of this logic by passing
-DQT_NO_STRIP_WRAPPER=TRUE when configuring each Qt repo.
Pick-to: 6.2 6.3
Fixes: QTBUG-101653
Change-Id: Idd213d48d087d3c9600c853362aebaba348cde33
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
QtCopyFileIfDifferent needs to be both installed and copied to a build
folder as a public CMake helper. Otherwise it's not found when building
tests inside the Qt build tree.
Pick-to: 6.2 6.3
Fixes: QTBUG-101916
Change-Id: I8d081e594fe694f528ebac4c13bbdf6d3b8402b9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
After the update to the CMake based build system the ability to
generate pkgconfig files, like it was with QMake, was lost.
This patch adds pkgconfig generation again via a new internal command
named qt_internal_export_pkg_config_file.
The functionality of this command consists in checking if the target
is internal. Then gets the compile definitions. It performs a search
for dependencies that is somewhat similar to
qt_get_direct_module_dependencies, although it won't recurse down for
more deps. Each dependency is then again, checked if it's internal or
has a public interface. Later these deps get deduplicated and lastly
a pkgconfig file is filled.
The resulting pkgconfig files of many of the Qt6 packages were
validated via invocations of `pkg-config --validate` and
`pkg-config --simulate` commands and later used to build local
projects plus tests that use the pkg-config provided details at
compilation time.
Although it has some limitations, with qt_internal_add_qml_module if
it specifies non-public deps these won't be listed and with non-Qt
requirements, notably in static builds, not being appended to the
PkgConfig file.
Task-number: QTBUG-86080
Change-Id: I0690bb3ca729eec328500f227261db9b7e7628f6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Bundle a default LaunchScreen.storyboard file for an iOS app and make
sure it's referenced in the generated Info.plist file.
When launching Qt examples, it ensures the app uses the whole screen
space on the device rather than just a square-ish part of it.
The storyboard file is a copy of the qmake one, which qmake adds
to the Xcode projects it generates.
A custom launch screen can be provided either by setting the
QT_IOS_LAUNCH_SCREEN variable or by setting the
QT_IOS_LAUNCH_SCREEN target property.
The value must be an absolute path to the launch screen file.
The automatic addition of the launch screen entry in the Info.plist
file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN
variable to TRUE.
The automatic bundling of the launch screen file in the application
bundle can be prevented by setting the
QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE.
The current implementation has a limitation that only one launch
screen storyboard and one iOS executable can exist within a project.
If there are multiple executables in the project, all of them will
use the launch screen that is specified last (the last
qt_add_executable call).
Because of this limitation, the API is marked as Technical Preview,
to be improved upon in the future. For now it simply serves as an
improvement to the out-of-the-box experience of iOS apps built
with CMake.
Amends 4d838dae5a
Pick-to: 6.2 6.3
Fixes: QTBUG-95837
Change-Id: I6b067d703d635122959a1ef17fcca713da694a86
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Use custom script to copy big Android artifacts on Windows platforms.
The script uses 'copy' but not 'copy_if_different' when source file
size is bigger than 2GB. 'cmake -E copy_if_different' only compares
first 2GB of files because of cmake issue, so this step only
workaround the problem.
Pick-to: 6.2 6.3
Task-number: QTBUG-99491
Change-Id: Id076734700e334dfc3330da412462c2b53829b33
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
They are used by build dir Qt6FooConfig.cmake files in conjunction
with export(EXPORT)'ed target files when building ExternalProjects
against a non-installed Qt (or in a top-level build).
Change-Id: I688caf1bd1b8a8fe7e549cebade2aef6f928bd6c
Pick-to: 6.2 6.3
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Use IMPORTED_LOCATION of rcc target when generating Android
deployment settings, instead of the hardcoded host path.
Introduce a helper function to find the location of the imported tool
target.
Change-Id: Icfa51ee7a01b3f58fc4892da03055f9ed531cc0b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The version script compile test did not use the linker that the build
system determined to use to link Qt, but rather the system linker.
Run qt_run_linker_version_script_support only after the global qtbase
features have been evaluated and make sure to include the active
linker flags.
Pick-to: 6.2 6.3
Change-Id: I0ff82406828daaf0dc5ec25a55f53ac7d98e3347
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Script that wraps Qt test execution in order to iron-out flakiness.
Task-number: QTBUG-96353
Change-Id: Ie8ee780e3f4f8d086c080a7784f9f68fd1867be2
Reviewed-by: Daniel Smith <Daniel.Smith@qt.io>
The qtpaths tool is supposed to replace "qmake -query", and it must be
available for cross-builds as a wrapper script like qmake.
Re-use the existing facility for creating the qmake wrapper script for
creating the qtpaths wrapper script.
Pick-to: 6.2
Fixes: QTBUG-97821
Change-Id: I460bae61a531994422e1c0fba09c79e4aa65713f
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>
Certain platform-related variables, in this case UNIX, must be set in a
platform module, because they get cleared after the toolchain file is
loaded. Such platform modules live in upstream CMake, but there is none
yet for INTEGRITY. This manifests in an undefined UNIX variable and
"System is unknown to CMake" warnings for the project and every
configure test.
Add the CMake module "Platform/Integrity" in the cmake/platforms
directory. Add this directory to CMAKE_MODULE_PATH to let CMake load
Platform/Integrity when the toolchain file set CMAKE_SYSTEM_NAME to
"Integrity".
CMake's module directory takes precedence, when loading platform
modules. This is special for platform modules and different from the
documented behavior of CMAKE_MODULE_PATH and include().
In case the user wants to provide their own platform modules via
CMAKE_MODULE_PATH, they can instruct Qt to not add its path by setting
QT_AVOID_CUSTOM_PLATFORM_MODULES to ON.
Make sure that configure tests with project files also load the custom
platform module.
Pick-to: 6.2
Fixes: QTBUG-96998
Change-Id: I9855d620d24dc66353cec5e847a2675b464ace26
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This reverts commit 657525965b.
The change relied on reading the last value of the
CMAKE_MINIMUM_REQUIRED_VERSION variable before one of the Qt packages
is found to use it for the version check.
Even if a user project has a cmake_minimum_required() right at
the beginning of the project with a supported version specified,
the first project() call which loads a CMake toolchain file could
contain another cmake_minimum_required() call with a lower
(unsupported) version and that version would be used for the check,
failing the project configuration.
The Android NDK ships such a toolchain file, which requires version
'3.6'.
Thus, relying on the last value of CMAKE_MINIMUM_REQUIRED_VERSION is
not robust enough.
Pick-to: 6.2
Task-number: QTBUG-95018
Task-number: QTBUG-95832
Change-Id: Iff3cb0a46e6e878569dce9c5fe915a714a034904
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Qt6Config.cmake calls cmake_minimum_required to ensure a recent enough
CMake version is used in projects.
That call does not set policies in the calling subdirectory scope,
because find_package introduces a new policy scope.
If a project using Qt has a 'cmake_minimum_required(VERSION 3.1)'
call and is configured with a recent CMake, many policies will
still be set to OLD.
One such policy is CMP0071 (Run AUTOMOC on GENERATED files). The
policy value is queried at generation time rather than at target
definition time, which means we can't influence the policy value
(e.g. inside the implementation of qt_add_executable for example)
The inability to influence the policy value for targets created by our
own CMake functions is unfortunate and can lead to issues (in the case
of the above policy to compilation / linker issues).
Record the version of the last cmake_minimum_required call before
the Qt packages are found and error out if the version is lower than
the minimum supported one.
A project can reduce the error into a warning by specifying a
-DQT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT_IN_CMAKE_MIN_REQUIRED=3.xyz
option when configuring the project.
If the option is used and build issues arise, no official support is
given.
All the CMake example projects shipped with Qt specify a minimum
version of 3.16 already (which is the minimum for shared Qt builds),
so it shouldn't be an issue to require that in other user projects as
well.
Implementation wise, we follow the existing pattern to record
what the minimum and computed versions for static and shared Qt
builds are at qtbase configure time.
These are then checked before the Qt6 or QtFoo packages are
find_package'd.
Amends 6518bcc167
Pick-to: 6.2
Task-number: QTBUG-95018
Task-number: QTBUG-95832
Change-Id: I1a1d06d82f566c92192a699045127943604c8353
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Split qt_auto_detect_wasm into multiple helper functions and place
them in a new QtPublicWasmToolchainHelpers.cmake file.
We want to use them to try and detect the CMake toolchain
file location from within the generated qt.toolchain.cmake
file whem configuring a user project.
Pick-to: 6.2
Task-number: QTBUG-96843
Change-Id: Id8c2350e6dbe3c994b435681353bdaee114249a7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Pass Qt6_FIND_VERSION to components when the
find_package(Qt6 ${ver} COMPONENTS Foo) signature is used.
Create a ConfigVersion file for BuildInternals, so that BuildInternals
passes the version check.
Fix qt_configure_file to look in the _qt_6_config_cmake_dir folder for
the template file rather than Qt6_DIR, because Qt6_DIR might be
accidentally unset after a failed find_package(Qt6) call and the error
is not helpful then.
We already pass versions everywhere else when looking for
dependencies, like in ModuleDependencies.cmake.in,
PluginDependencies.cmake.in, ModuleToolsDependencies.cmake.in.
Pick-to: 6.2
Fixes: QTBUG-91737
Change-Id: Ief1da0c6f239c935385e7ce662951e85ccfdf130
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This change introduces new behavior to error out when configuring user
projects if the CMake version used is too old for Qt to work with.
The main motivator is the requirement of new CMake features to ensure
object libraries are placed in the proper place on the link line in
static builds.
The minimum CMake version is computed based on whether Qt was
configured as shared or static libraries.
At the moment the required versions for building and using Qt are the
same.
The minimum versions are defined in qtbase/.cmake.conf in the
following variables
QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_SHARED
QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_STATIC
QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_SHARED
QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_STATIC
Qt Packagers can disable the version check when configuring Qt
by setting
QT_FORCE_MIN_CMAKE_VERSION_FOR_BUILDING_QT and
QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT.
In this case it is the packagers responsibility to ensure such a Qt
works correctly with the specified CMake version.
User projects can also set QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT
to disable the version check. Then it's the project's developer
responsibility to ensure such a Qt works correctly.
No official support is provided for these cases.
Implementation notes.
The versions required to build Qt are stored in
QtBuildInternalsExtra.cmake
whereas the versions required to use Qt are stored in a new
QtConfigExtras.cmake.
Also the policy range variables stored in
QtBuildInternalsExtra.cmake are now regular variables instead of cache
variables, to properly allow overrides per-repository.
Some renaming of functions and variables was done for a bit more
clarity and easier grep-ability.
Pick-to: 6.2
Task-number: QTBUG-95018
Change-Id: I4279f2e10b6d3977319237ba21e2f4ed676aa48b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Ensure that Qt user projects build with sanitizer flags if Qt was
configured with any of the sanitizers enabled.
To compile Qt with sanitizer support enable any of Qt sanitizer
features.
Passing -DECM_ENABLE_SANITIZERS=address to CMake is NOT supported
anymore.
When configuring Qt using CMake directly, pass
-DFEATURE_sanitizer_address=ON
-DFEATURE_sanitizer_undefined=ON
instead of
-DECM_ENABLE_SANITIZERS=address;undefined
When configuring Qt with the configure script pass
-sanitize address -sanitize undefined
as usual.
QtConfig.cmake now records the sanitizer options that should be
enabled for all consuming projects based on the enabled Qt features.
This applies to internal Qt builds as well as well as tests an
examples.
The recorded sanitizer options are assigned to the ECM_ENABLE_SANITIZERS
variable in the directory scope where find_package(Qt6) is called.
The ECMEnableSanitizers module is included to add the necessary flags to
all targets in that directory scope or its children.
This behavior can be opted out by setting the
QT_NO_ADD_SANITIZER_OPTIONS variable in projects that use Qt and might
be handling sanitizer options differently.
Amends 7e03bc39b8
Pick-to: 6.2
Fixes: QTBUG-87989
Task-number: QTBUG-92083
Change-Id: I2e3371147277bdf8f55a39abaa34478dea4853a6
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Add an option that automatically generates an export header for a Qt
module. The header contains only Q_DECL_EXPORT/Q_DECL_IMPORT related
content, so it's not a full replacement of 'global' header files.
Task-number: QTBUG-90492
Change-Id: I250d1201b11d4096b7e78e61cbf4565945fe6517
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Dependency lookup mechanism is the same for modules and plugins. It
makes sense to wrap it using macro.
Pick-to: 6.2
Change-Id: I73727743b0f5f40b2d94624f65ebfcf85e8dcc59
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Remove target specific flags from static_link_order.
Move the check to the common config.tests folder.
Amends 5fb99e3860
Pick-to: 6.2
Task-number: QTBUG-93002
Task-number: QTBUG-94528
Change-Id: I1368075ec6bd1e743b2b89fd93143df38a278ec2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This makes qt_internal_disable_find_package_global_promotion available,
which is needed when linking against QtMultimedia in a static build
Pick-to: 6.2
Change-Id: I9b8f6d7b74a8693ac471f8a280e893f4da80a44b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
'ld' only capable to resolve circular dependencies by wrapping the
suspected static libraries and objects using --start/end-group
arguments. We want to detect if linker is 'ld' at configure time to
decide how to link the resource objects if finalizers are not enabled.
The qt_config_compile_test function is extended with an extra argument
since it's required to pass custom cmake flags to the ld-related test.
Pick-to: 6.2
Change-Id: I484fcc99e2886952d8b0232f37e4e6a35d072931
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
All repositories define QT_NO_INTERNAL_COMPATIBILITY_FUNCTIONS by now,
and we can remove QtCompatibilityHelpers.cmake altogether.
Change-Id: I4d8104246e96a4514d5651c104607d651d208d95
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This proposal collects all the resource objects to the qt-specific
property of the static libraries. This is done to avoid littering
of other static libraries and put resource object files to the
source part of the linker line when linking the end-point
executable.
The way we link object resource libraries is changed back to the
target_link_libraries approach as we may omit using finalizers
with linkers other than ld. Users may enforce finalizers by calling
the qt6_enable_resource_objects_finalizer_mode function if need.
Refactor tests related to the static resources.
Amends ddaa7150d8
Task-number: QTBUG-93002
Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Introduce the concept of repository target sets, which is a named set of
targets within a Qt module repository.
In a Qt repository, a repo target set 'qtfoo' can be defined in the
top-level project file with
qt_internal_define_repo_target_set(qtfoo DEPENDS Bar Baz)
The DEPENDS argument specifies Qt components that need to be
find_package'd when building the targets that belong to qtfoo.
In subdirectory project files, use
qt_internal_include_in_repo_target_set(qtfoo) to mark the file as
belonging to the repo target set.
To build and install a single repo target set, specify
QT_BUILD_SINGLE_REPO_TARGET_SET=qtfoo when configuring the Qt
repository.
Change-Id: Ic9e6213e3225988fd561f315bc857ee44ff17420
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Needed for the upcoming static plugin mechanism, where we have to
extract the list of Qt module dependencies of a target and then extract
the plugins associated with those modules.
To do that we need to recursively collect the dependencies of a given
target.
Rename the moved functions to contain the __qt_internal prefix.
Also rename the existing QtPublicTargetsHelpers.cmake into
QtPlatformTargetHelpers.cmake to avoid confusion with the newly
introduced QtPublicTargetHelpers.cmake.
Task-number: QTBUG-92933
Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Extract common static plugin handling functionality into a separate
QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package.
Split the code into smaller functions that will be re-used by each
templated QtPlugins.cmake.in file, rather than copy pasting the same
code into each QtFooPlugins.cmake file.
As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake
as public helper files just like QtPublicPluginHelpers.cmake.
This makes it clearer that the functions are available outside
the internal Qt build and also provides a way for not dumping new
helper functions into Qt6CoreMacros.cmake.
Task-number: QTBUG-92933
Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
It's important for conan CI builds where the correct installation
location of Qt should be used when configuring standalone tests.
Task-number: QTBUG-93037
Change-Id: I2465a439aea6826dedfb3217d1c909ad639d4ac0
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add an iOS specific plist file like we do for macOS.
If the user hasn't specified a bundle identifier or a development
team id, do what qmake does and query the Xcode preferences file to
pre-populate those if possible.
This allows running
cmake -GXcode ./foo
on a Qt example project and building it with xcodebuild on the
command line without having to go through the IDE to set a development
team id or modifying the example project to add a product
bundle identifier.
Note that the change assumes that the development team id has been
previously set / configured via Xcode. If no such id is found, then
the value will not be set and the user will still have to specify it
either in the project file or via the Xcode UI after the project
has been generated.
Amends 3a2fa3fec5
Pick-to: 6.1
Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Use the same approach we use for iOS, which is to set multiple
CMAKE_OSX_ARCHITECTURES values and let the clang front end
deal with lipo-ing the final libraries.
For now, Qt can be configured to build universal macOS libraries by
passing 2 architectures to CMake, either via:
-DCMAKE_OSX_ARCHITECTURES="x86_64;arm64"
or
-DCMAKE_OSX_ARCHITECTURES="arm64;x86_64"
Currently we recommend specifying the intel x86_64 arch as the first
one, to get an intel slice configuration that is comparable to a
non-universal intel build.
Specifying the arm64 slice first could pessimize optimizations and
reduce the feature set for the intel slice due to the limitation
that we run configure tests only once.
The first specified architecture is the one used to do all the
configure tests.
It 'mostly' defines the common feature set of both architecture
slices, with the excepion of some special handling for sse2 and
neon instructions.
In the future we might want to run at least the Qt architecture config
test for all specified architectures, so that we can extract all the
supported sub-arches and instruction sets in a reliable way.
For now, we use the same sse2 hack as for iOS simulator_and_device
builds, otherwise QtGui fails to link due to missing
qt_memfill32_sse2 and other symbols.
The hack is somewhat augmented to ensure that reconfiguration
still succeeds (same issue happened with iOS). Previously the sse2
feature condition was broken due to force setting the feature
to be ON. Now the condition also checks for a special
QT_FORCE_FEATURE_sse2 variable which we set internally.
Note that we shouldn't build for arm64e, because the binaries
get killed when running on AS with the following message:
kernel: exec_mach_imgact: not running binary built against
preview arm64e ABI.
Aslo, by default, we disable the arm64 slice for qt sql plugins,
mostly because the CI provisioned sql libraries that we depend on only
contain x86_64 slices, and trying to build the sql plugins for both
slices will fail with linker errors.
This behavior can be disabled for all targets marked by
qt_internal_force_macos_intel_arch, by setting the
QT_FORCE_MACOS_ALL_ARCHES CMake option to ON.
To disble it per-target one can set
QT_FORCE_MACOS_ALL_ARCHES_${target} to ON.
Task-number: QTBUG-85447
Change-Id: Iccb5dfcc1a21a8a8292bd3817df0ea46c3445f75
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
A few configure defines get changed:
QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE
QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY
QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE
device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1
To create source maps for debugging. use
device-option QT_WASM_SOURCE_MAP=1
Task-number: QTBUG-78647
Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When a CMake release introduces a new policy that affects most Qt
modules, it may be appropriate to make each module aware of that newer
CMake version and use the NEW policy without raising the minimum CMake
version requirement. To reduce the churn associated with making that
change across all Qt modules individually, this change allows it to be
updated in a central place (qtbase), but in a way that allows a Qt
module to override it in its own .cmake.conf file if required (e.g. to
address the issues identified by policy warnings at a later time). The
policies are modified at the start of the call to
qt_build_repo_begin().
For commands defined by the qtbase module, qtbase needs to be in
control of the policy settings at the point where those commands are
defined. The above mechanism should not affect the policy settings for
these commands, so the various *Config.cmake.in files must not specify
policy ranges in a way that a Qt module's .cmake.conf file could
influence.
Starting with CMake 3.12, policies can be specified as a version range
with the cmake_minimum_required() and cmake_policy() commands. All
policies introduced in CMake versions up to the upper limit of that
range will be set to NEW. The actual version of CMake being used only
has to be at least the lower limit of the specified version range.
This change uses cmake_minimum_required() rather than cmake_policy()
due to the latter not halting further processing upon failure.
See the following:
https://gitlab.kitware.com/cmake/cmake/-/issues/21557
Task-number: QTBUG-88700
Pick-to: 6.0
Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We want to remove the Qt .pro files for projects, except examples,
because examples are still meant to build with qmake.
To not lose coverage on examples built with qmake, add instructions that
will build the qtrepo/examples folder with qmake when the CMake
configuration has -DQT_BUILD_EXAMPLES=ON.
This means that such configurations will build examples both with CMake
and qmake.
Aside from making sure that our examples will still build with qmake, it
will gives us some some coverage that a CMake-built qmake works
correctly.
Implementation-wise, add new instructions files that can call qmake and
make depending on configuration and target type.
Pick-to: 6.0
Fixes: QTBUG-85986
Change-Id: Ie8f4cbcda03c94da2aef455e32f48dad41a4bdb0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...and include it in QtBuild.cmake.
Commit e8d8b1a5e4 added two different code paths to include
QtBuildInternalsAndroid.cmake.
This was needed, because:
In a top-level build, we must not include files that are not yet
installed. We have the source tree available, and
"${QT_SOURCE_TREE}/cmake" is in CMAKE_MODULE_PATH.
We can use the "module syntax" of the include() command.
In a per-repository build, when building against an installed qtbase, we
must not include files of the source tree, because that's not guaranteed
to be available. However, Qt6BuildInternalsConfig.cmake is installed,
and we can directly include QtBuildInternalsAndroid.cmake, which is
right next to it.
We can circumvent this whole issue by moving the Android-related
functions out of the Qt6BuildInternals package and including it in
QtBuild.cmake.
Pick-to: 6.0
Task-number: QTBUG-88718
Change-Id: I5192ba19bb77952505c20d053d7285f798d16ac5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The EntryPoint interface target now contains all the logic
for what flags and optional static libraries to add when the
entrypoint is enabled.
The target property QT_NO_ENTRYPOINT can be used to disable
the entrypoint.
Change-Id: I9b14ff729366cd6307789c969ebd4b2ca19de77d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add a new function that returns the minimum CMake version required to
build Qt. Pass that value to cmake_minimum_required() when building
qtbase and its standalone tests.
The minimum supported CMake version is read from qtbase/.cmake.conf
and its value should be updated when the need arises. It's the main
source of truth for all repos.
Provide a way to lower the minimum CMake version at configure time by
passing a value via QT_FORCE_MIN_CMAKE_VERSION.
This is not an officially supported way of building Qt. If the
specified version is lower than Qt's supported minimum, show a
warning.
Nevertheless the option is useful for testing how Qt builds with a
different minimum CMake version due to different policies being
enabled by default.
Issue warnings for CMake versions that are higher than the minimum
version but are known to cause issues when building Qt.
A counterpart change is needed in qt5 to ensure the minimum CMake
version is set at the proper time for top-level builds.
Ideally we would use the same 'check the CMake minimum version` code
in all our repositories, but that will cause lots of duplication because
we can't really find_package() the code and doing something like
include(../qtbase/foo.cmake) hardcodes assumptions about repo
locations.
So for now we don't bump the minimum version in child repo
cmake_minimum_required calls (qtsvg, qtdeclarative, etc).
Instead we record both the minimum supported version and the computed
minimum version (in case a different version was forced) in
QtBuildInternalsExtra.cmake.
Then we require qtbase's computed min version in
qt_build_repo_begin().
This won't set policies as cmake_minimum_required would, but at least
it propagates what minimum CMake version should be used for child
repos.
We might still have to bump the versions in child repos at some point.
Task-number: QTBUG-88086
Change-Id: Ida1c0d5d3e0fbb15d2aee9b68abab7a1648774b9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Passing arguments with equal signs was broken for configure.bat and
qt-configure-module.bat. An argument FOO=BAR was split at = and written
as
FOO
BAR
to config.opt, breaking every attempt of assigning CMake variables.
We must not iterate over %* in batch files to avoid splitting arguments
at equal signs. Instead, pass %* unmodified to a CMake script that
writes config.opt.
Fixes: QTBUG-88019
Change-Id: I7c743a206961d1ed168f2313f864905f6b345b49
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For top-level builds it's desirable to have "ninja generate_docs" build
all tools needed to generate the documentation.
This is problematic since the doc-generating targets are created before
the doc tool targets. Thus, we must defer the dependency connection if
the doc tool target is not yet available.
This patch adds the functions qt_internal_defer_dependency and
qt_internal_add_deferred_dependencies.
Change-Id: Ica940b80882e67cb0e0943e95541f7f4d1885948
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And wrap the various behaviors into separate functions.
Change-Id: If940351af34e445de050f2b46301de7080b1555b
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
It appears that CMake's Xcode generator default behavior can't really
handle imported object libraries location, which Qt uses extensively
(all the qt_add_resource calls).
Specifically the project fails to configure with the following error
message:
The OBJECT library type may not be used for IMPORTED libraries under
Xcode with multiple architectures.
An issue was filed upstream at
https://gitlab.kitware.com/cmake/cmake/-/issues/21276
In the mean time, it looks like it's possible to work around the issue
by setting XCODE_EMIT_EFFECTIVE_PLATFORM_NAME global property to OFF.
This needs to be done before the very first project() call, so we do
it in the generated Qt toolchain file.
Note that the workaround only works if the CMake project is configured
with a single architecture given to CMAKE_OSX_ARCHITECTURES.
If multiple arches are given, it will fail with the same error
message.
Fixes: QTBUG-87198
Change-Id: I2556ae28b2fc2d9cfe464a5acf9c4fcbaf01b654
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add an abstraction over Qt::WinMain (aka qtmain.lib) and
iOS's runtime linker entry point (_qt_main_wrapper).
The Core target will now link against the Startup target on all
platforms, instead of just WinMain on Windows.
The creation and linkage interface definition of the Startup target
is done at find_package(Qt6Core) time via the private call of
_qt_internal_setup_startup_target().
This will add automatic linkage of WinMain to executables marked with
the WIN32_EXECUTABLE property on Windows.
As well as the addition of the '-Wl,-e,_qt_main_wrapper' linker flag
when linking iOS executables.
Qt users can opt out of this behavior by either setting the
QT_NO_LINK_QTMAIN property or variable. This is in line with
Qt 5 behavior.
Task-number: QTBUG-87060
Change-Id: I7d5e9f1be0e402cf8e67e6f55bfd285f9e6b04f4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
If a consumer wants to cross-compile a Qt app, they need to provide
the host Qt path location.
When building Qt in the CI we embed the Qt host path into the
generated CMake toolchain file for convenient building of other Qt
modules.
But once Qt is built, packaged and installed on a user's machine, most
likely the Qt host path will not be the same. In such a case, if the
user wants to use the convenience toolchain, they should explicitly
provide the Qt host path via the QT_HOST_PATH and
QT_HOST_PATH_CMAKE_DIR variables.
Show an error message if the values are not provided or don't exist
on the file system.
It's possible that in the future the Qt installer will patch the
toolchain file, or provide additional info, to point to the host
Qt installation so that the user doesn't have to do it manually.
But until that's done, a friendly error message is a good way to
inform the user what they should do.
Task-number: QTBUG-83999
Change-Id: I26291e3c47bb77375f8a5ce7b848c0382a660ca9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Public consumers of the qt toolchain file will most likely not have
their compilers in the same location where they were on the Qt build
machine.
Only set the compiler paths if none was set already, and the paths
actually exist.
This seems to become a trend in the generated toolchain file, and is
only a stop-gap solution.
A proper solution (two different toolchain files) may follow.
Task-number: QTBUG-83999
Change-Id: I7a603af447333a45c65b98e299ee109932d16517
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
