Commit Graph

1502 Commits

Author SHA1 Message Date
Juha Vuolle
17d7a8dc2e Update Android default SDK from 29 to 30
By the time of Qt 6.2 release all new apps targeting Play store must
target API level 30 (Android 11) or above (starting in 08/2021 for
new apps and 11/2021 for existing apps' updates).

Pick-to: 6.2 5.15
Task-number: QTBUG-94451
Change-Id: Id7fa2fd62899a7259e365c917292c6c3ac0d2b0d
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
2021-08-27 18:31:17 +00:00
Joerg Bornemann
f9e9d21a11 CMake: Error out if ccache is requested but not found
Before, we would just issue a warning which is likely to get overlooked
in CMake's output.  Also, the configure summary would report "Using
ccache ... yes" but CMAKE_<LANG>_COMPILER_LAUNCHER stays unset, which is
inconsistent.

Make QT_USE_CCACHE=ON and missing ccache a hard error.

Task-number: QTBUG-88308
Change-Id: Iddc7f3a91428fd96ad0defbb1ca72bd46a90aa98
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-27 16:29:49 +02:00
Joerg Bornemann
d94652f792 Call MinGW's ld with -Bstatic when requesting static runtime linkage
The -static argument we used before is supported by ld, but not lld.
The latter requires --static or -Bstatic.  Use -Bstatic, which is
supported by both.

Pick-to: 6.2
Fixes: QTBUG-89549
Change-Id: I3c3069661bf4cd20e3298aff4714163b7419d3ef
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-27 15:45:25 +02:00
Alexey Edelev
e1fe816d46 Implement generating of private cpp exports
Add the generating of private cpp exports for Qt modules.

Add the GENERATE_PRIVATE_CPP_EXPORTS option to qt_internal_add_module
that is the manual switch for private exports generator. Existing
modules in qtbase doesn't follow any strict convention of using
private cpp export. So there is no clue how to detect if generating of
the private exports is required or not for the module.

Use autogenerated private cpp exports in QtNetwork module.

CPP_EXPORT_HEADER_NAME argument of the qt_internal_add_module function
is replaced by the CPP_EXPORT_HEADER_BASE_NAME and has a different
meaning. The provided name is used as a base name for the private and
non-private headers that contains cpp exports. Header files suffixes
are constant: .h and _p.h for the non-private and private header files
accordingly.

Pick-to: 6.2
Task-number: QTBUG-90492
Change-Id: Icf11304e00379fb8521a865965c19b974e01e62f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-08-27 11:01:47 +02:00
Alexey Edelev
928ffbd1e2 Use correct module include name across the project
Module may have specific module include name that should be taken into
account when specifying module include directories in different places.
The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to
the common naming rules and the property is used to preform include
paths instead of the direct use of the module name.

Add additional paths generated by qt_internal_module_info to keep them
consistent across all cmake files.

Pick-to: 6.2
Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-27 11:01:38 +02:00
Alexandru Croitor
0dbf73e3de CMake: Warn when PRIVATE_MODULE_INTERFACE is provided with no target
Warn if the PRIVATE_MODULE_INTERFACE option is provided a value, but
there is no ${target}Private target to set the interface dependencies
on.

Pick-to: 6.2
Task-number: QTBUG-95921
Change-Id: I7d4df9cb3aa9b7746d836b82019ecdd9c8f50fdc
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-26 16:40:15 +02:00
Alexandru Croitor
d806ce6fc5 CMake: Properly export MODULE_PLUGIN_TYPES
Don't export the MODULE_PLUGIN_TYPES property only when a module has
an associated configure.cmake file with features. Instead, always
export it if a module defines a plugin type.

This fixes qttools DesignerTargets.cmake file to contain the plugin
types it defines, given that the Designer lib does not declare any
features via a configure.cmake file.

Pick-to: 6.2
Task-number: QTBUG-95668
Change-Id: Ic036c31768e03b51d3bce9c2afe48e04f69f435b
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-26 11:36:27 +00:00
Alexey Edelev
abb19da572 Add missing PRIVATE_MODULE_INTERFACEs to INTERNAL_MODULEs
To detect the internal module ouside the qt_internal_add_module
function need to mark it with the property.
This adds _qt_is_internal_module property to the Qt internal modules.
Since PRIVATE_MODULE_INTERFACE only was applicable to pure Private
modules, INTERNAL_MODULEs is missing those dependencies if they were
specified. Add extra condition to qt_internal_extend_target to link
PRIVATE_MODULE_INTERFACE libraries to internal modules as well.

Pick-to: 6.2 6.1
Change-Id: I9c32fa5bad3aff365f5d7663349e5365d5f1d72d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-24 20:58:39 +02:00
Alexandru Croitor
3c1125d9fe CMake: Create plugin initializers for static user plugins
Previously we only created object library static plugin initializers
for Qt plugins only, not user-project plugins.

The reason was that if a user tried to install the plugin target via
an export set, CMake would error out saying that the _init library is
not part of the same export set.

Introduce an OUTPUT_TARGETS option that would allow projects to get
the name of the generated _init target, so they can install it if
needed.
This was already done for qt6_add_qml_module, so we just introduce the
same option for qt6_add_plugin.

Now user static plugins will have an _init target created, which will
be propagated to consumers whenever the consumers link against the
plugin itself.

We also need an internal option to disable this propagation, because
it's handled a bit differently for Qt plugins which can be linked
either via finalizers or via usage requirements.

Amends 91c65dd80c

As a result of the implementation change, cleanup example projects
to ensure that they build successfully (the important part is
specifying the CLASS_NAME).

Only plugandpaint works properly with both shared and static Qt
builds.

echoplugin works with a shared Qt build, but not a static one due to
some assumptions in the C++ code about shared plugins.

styleplugin doesn't seem to work properly neither with shared Qt
builds nor static Qt builds, at least on macOS. But it builds fine.
For some reason even if the plugin is found, the style is not applied.

Amends 4caac1feea

Pick-to: 6.2
Task-number: QTBUG-80863
Task-number: QTBUG-92933
Change-Id: I6f631cda9566229b7a63992b23d7d7fa50303eeb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-24 16:10:31 +02:00
Joerg Bornemann
278368b523 CMake: Fix excessive size of precompiled header files
Do not add catch-all header files like QtCore, QtGui, etc. to
precompiled headers for targets that already define their own set of
precompiled header files.

This reduces the size of the precompiled headers and brings the pch file
sizes down into the region of the qmake build.

Pick-to: 6.2
Task-number: QTBUG-89122
Change-Id: I8e4d17aa6829c7d7b1aa01a01a61b6677e22c460
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-24 14:50:12 +02:00
Joerg Bornemann
1ac947e3af Add missing -help argument to qt-configure-module
Now it's possible to display a configure help screen per module with
  qt-configure-module <module-source-dir> -help

Pick-to: 6.2
Fixes: QTBUG-95943
Change-Id: I7d26006246af4b38b5a2ec6deca3f45c5313afec
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-20 19:44:43 +02:00
Joerg Bornemann
57ad532e75 Fix our usage of CMake script mode in Windows configure
This is a preparation for adding the -help argument to
qt-configure-module.bat.

Consider the call
  qt-configure-module.bat path/to/qt-module -help
Internally, we called
  cmake ... -P .../QtWriteArgsFile.cmake path/to/qt-module -help
which was supposed to separate the arguments and write them into
config.opt.

However, passing arbitrary arguments after "-P script.cmake" only worked
by accident and is not supported.  As soon as arguments are passed that
are valid CMake arguments, like -help or -G, the CMake call would fail.

Now, we let configure.bat and qt-configure-module.bat write the
arguments as is into config.opt.in and let QtWriteArgsFile.cmake read
this file, separate the arguments and write config.opt.

Pick-to: 6.2
Task-number: QTBUG-95943
Change-Id: I80f298a2aaf55b0f79fed86320a055eb2d2b6faa
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-20 19:44:43 +02:00
Joerg Bornemann
6e48d654d7 Don't force lld for Android when clang is used
This reverts commit 64c111e10f.

The claim of the commit message, that we cannot use the gold linker,
does not seem to be true (anymore?).  This is underlined by the fact
that CMake *forces* the gold linker for Android, whenever LTCG is
enabled (see Modules/Compiler/Clang.cmake as of CMake 3.21.1).

Change-Id: I90edac8555be4abdd44cd367228aeffb0d66b895
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-08-20 17:19:20 +02:00
Joerg Bornemann
80de516565 Fix Android -ltcg build
We're passing -Oz for release builds, but that's not a flag the linker
understands when -ltcg is enabled.  The build fails with:
    ld.gold: fatal error: Optimization level must be between 0 and 3

Fix this by using -O2, which -Oz is based on, and -O3 for the "full
optimization" that is used for core and gui.

Pick-to: 6.2
Fixes: QTBUG-89472
Change-Id: Ie1a86888baefce5ca97026e7d635f10d2819f9f4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-20 09:48:27 +02:00
Alexandru Croitor
6544312869 CMake: Pass Qt6_FIND_VERSION in Qt6Config when looking for components
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>
2021-08-19 16:42:56 +02:00
Alexandru Croitor
6b6d42f6b8 CMake: Fix QT_ADDITIONAL_PACKAGES_PREFIX_PATH for cross-builds
The QT_ADDITIONAL_PACKAGES_PREFIX_PATH variable was introduced to
allow specifying extra locations to find Qt packages.

The reason it was introduced instead of just using CMAKE_PREFIX_PATH
is because the Qt6 component find_package call uses NO_DEFAULT_PATH
which means CMAKE_PREFIX_PATH is ignored.
We use NO_DEFAULT_PATH to ensure we don't accidentally pick up
system / distro Qt packages.

The paths from QT_ADDITIONAL_PACKAGES_PREFIX_PATH are added to the
find_package PATHS option in the Qt6 package, each
ModuleDependencies.cmake file and some other places.

Unfortunately that's not enough to make it work for cross-builds.

Imagine the following scenario.

  host qtbase, qtdeclarative installed in /host_qt
  target qtbase installed in /target_qtbase
  target qtdeclarative installed in /target_qtdeclarative

We want to cross-build qtlottie.

We configure qtlottie as follows
 /target_qtbase/bin/qt-configure-module /qtlottie_src -- -DQT_ADDITIONAL_PACKAGES_PREFIX_PATH=/target_qtdeclarative

We expect the target QtQuick package to be found, but it won't be.

The reason is that QT_ADDITIONAL_PACKAGES_PREFIX_PATH is added to the
PATHs option, but we don't adjust CMAKE_FIND_ROOT_PATH.

Without adding the new paths in CMAKE_FIND_ROOT_PATH, CMake will
re-root the passed PATHs under the existing CMAKE_FIND_ROOT_PATH,
which is QT_TOOLCHAIN_RELOCATABLE_INSTALL_PREFIX, which evaluates to
/target_qtbase. There is no QtQuick package there.

To fix this, prepend the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH
to CMAKE_FIND_ROOT_PATH.

The location where we currently do CMAKE_FIND_ROOT_PATH manipulations
is in the qt.toolchain.cmake file, so to be consistent, we prepend the
new prefixes there as well.

We need to adjust both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH,
due the path re-rooting bug in CMake.
See https://gitlab.kitware.com/cmake/cmake/-/issues/21937 as well as
the existing comment in qt.toolchain.cmake marked with
REROOT_PATH_ISSUE_MARKER.

We also need to do a few more things to make the setup work

Because Qt6Config uses NO_DEFAULT_PATH, the CMAKE_PREFIX_PATH
adjustments we do in the toolchain file are not enough, so we still need
to add the same prefixes to the Qt6Config find_package PATHS option.

One would ask why do we need to adjust CMAKE_PREFIX_PATH at all then.
It's for find_package(Qt6Foo) calls to work which don't go through
the Qt6Config umbrella package.

To make the CMake re-rooting behavior happy, we need to ensure the
provided paths are absolute.
So we iterate over the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH,
to make them absolute. We do the same for the environment variable.

We need to append lib/cmake to the prefixes which are added to
CMAKE_PREFIX_PATH, otherwise the CMake re-rooting bug is hit.

We need to specify the Qt6 package location (${_qt_cmake_dir}) to the
PATHS option in the various Dependencies.cmake.in files, to ensure
that dependency resolution can jump around between the Qt6 dir and
the additional prefixes. Previously the dependency lookup code assumed
that all dependencies would be within the same prefix.

The same is needed for qt and qml plugin dependency lookup.

Amends 7bb91398f2
Amends 60c87c6801
Amends 5bbd700124

Pick-to: 6.2
Fixes: QTBUG-95854
Change-Id: I35ae82330fec427d0d38fc9a0542ffafff52556a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-19 16:42:56 +02:00
Alexandru Croitor
d65ccd3999 CMake: Don't backup cmake prefix when there are no tool dependencies
This is just a minor optimization.

Pick-to: 6.2
Change-Id: Icf0fc615895e1def63c57a72694c89f7ae7ee5cf
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-19 16:42:56 +02:00
Alexey Edelev
2059d294eb Remove unnecessary version of module from _MODULE_DEPENDENCIES
_<module>_MODULE_DEPENDENCIES variable in the
<module>Dependnecies.cmake should only contain the list of targets that
module depends on, but not versions. Version of the first module
appears in the list because of the regression introduced in
425ff34aa1

Amends 425ff34aa1

Pick-to: 6.2
Change-Id: Iaa42120af6bac742bdf0f8d389bd8e5bdef9c1d1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-19 13:35:40 +02:00
Alexandru Croitor
e7455644a2 CMake: Don't install metatypes files for user projects
Installing extracted metatypes json files for user projects was an
oversight. We shouldn't install anything on behalf of user projects,
but rather give them enough information so they can do it the
themselves.

Make all the install options of qt6_extract_metatypes internal,
change the behavior not to install the files by default, unless
__QT_INTERNAL_INSTALL is passed, which is used for the Qt build only.

__QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from
projects.

This is behavior change for existing public API, but it's better to
fix this now before 6.2.0 release.

Introduce a new OUTPUT_FILES option to allow assigning the extracted
metatype file paths into a variable that the project provides.
The project can then install the files where they need them.

[ChangeLog][CMake] qt6_extract_metatypes does not install metatypes
files anymore. Instead the OUTPUT_FILES option can be provided to get
the list of extracted files for further processing.

Pick-to: 6.2
Task-number: QTBUG-95845
Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-08-19 13:35:40 +02:00
Alexandru Croitor
a52b24ac39 CMake: Include quiet packages in feature summary
This will show packages that were found (or not) with
find_package(QUIET) in summary just before the configure summary.

It's useful for CI logs to determine whether some Qt packages was not
found when cross-compiling.

Pick-to: 6.2
Change-Id: Ic7d5062cf061f7c60b5c74374f957065dd8029f5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-18 22:15:35 +02:00
Kai Köhne
d2359b2d4e Pick up *Tools components also from host Qt
Let find_package(Qt6 COMPONENTS LinguistTools) for a cross-compiled
Qt fall back to search LinguistTools in the host Qt.

Use the same trick as in QtModuleDependencies.cmake: Prepend both
CMAKE_PREFIX_PATH and CMAKE_FIND_ROOT_PATH with the QT_HOST_PATH
(respective ${QT_HOST_PATH}/lib/cmake).

Furthermore adding ${QT_HOST_PATH}/lib/cmake to PATHS argument
makes sure that find_package will work even with NO_DEFAULT_PATH.

Make sure not to match ShaderTools and Tools packages.
ShaderTools is the cross-compiled package, the host package name is
ShaderToolsTools.
Tools is the cross-compiled module from qttools.

Allow an opt out via a QT_NO_FIND_HOST_TOOLS_PATH_MANIPULATION
variable in case that we accidentally match more packages ending in
Tools that are actually cross-compiled packages.

Pick-to: 6.1 6.2
Fixes: QTBUG-95602
Change-Id: Ib0a787716fa529e36f22356da069e705d9eed5fa
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-18 18:38:16 +02:00
Alexandru Croitor
ae6a8ddf45 CMake: Remove deprecated CFBundleLongVersionString from Info.plist
The CFBundleLongVersionString Info.plist entry has been deprecated and
removed from Apple documentation for a long time now.

Remove it.

Pick-to: 6.2
Task-number: QTBUG-95838
Change-Id: I4e4f74e00d678fd67875976c8884a80cdbb8cec4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-08-17 21:30:34 +02:00
Alexandru Croitor
3d2dc88850 configure: Fix iOS option to be passed for both platform and xplatform
Task-number: QTBUG-95838
Pick-to: 6.2
Change-Id: If0617e1d9c47595d4a350a91ab4f7d47546ebf08
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 21:30:34 +02:00
Alexandru Croitor
67dae9e6ee CMake: Save value of QT_UIKIT_SDK in QtBuildInternalsExtra.cmake
The value of QT_UIKIT_SDK is used in configure tests via
qt_config_compile_test -> qt_get_platform_try_compile_vars.

Up till now QT_UIKIT_SDK was only available in qtbase only.

Save the value in BuildInternals to ensure it's used for other repos
as well.

Change-Id: I46f372267782f1c8e7d48c237fe0264ac72d33bb
Pick-to: 6.2
Task-number: QTBUG-95838
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 21:30:34 +02:00
Alexandru Croitor
fe40e08da4 CMake: Fix building iOS projects with a single-arch Qt build
Automatically set the CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES
values with the ones Qt was configured with, when configuring a user
project with the Xcode generator and a single arch / sdk Qt build.

This ensures that calling xcodebuild from the command line chooses the
correct architecture and SDK when building the project.

Allow to opt out of this behavior by passing
QT_NO_SET_OSX_ARCHITECTURES and QT_NO_SET_OSX_SYSROOT.

Amends 55a15a1c1b
Amends a6a3b82ffb

Pick-to: 6.2
Task-number: QTBUG-95838
Change-Id: Ifab16e9eee3100a9b80a2a14b3ea29ba8d9aa6fc
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 21:30:34 +02:00
Joerg Bornemann
153fd84c8a CMake: Suggest "ninja install" for multi-config builds
The configure summary now suggests "ninja install" for Ninja
Multi-Config builds, because "cmake --install ." does not install all
configurations.  See CMake upstream issue #21475.

Pick-to: 6.2
Change-Id: Ie3129a906945db9d09c6772ce66ec7239797b8fc
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-17 19:18:54 +02:00
Joerg Bornemann
eafbda4191 CMake: Fix feature evaluation for feature defines
Passing -DFEATURE_developer_build=TRUE did not add the define
QT_BUILD_INTERNAL to src/corelib/global/qconfig.h like
-DFEATURE_developer_build=ON would.

This happened, because the feature evaluation in
qt_evaluate_feature_definition did a string comparison against "ON".

Normalize both sides of the string comparison, and thus support all
booly values for features.

Pick-to: 6.2
Fixes: QTBUG-95732
Change-Id: Ibf03579c05919b35219438361fc93676b7cca7cc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-17 09:23:40 +02:00
Joerg Bornemann
b43afd5315 CMake: Make precompiled headers work for Android on Windows
When building Qt for Android on Windows, the precompile_headers test
failed if the source directory was passed as absolute path without drive
letter.  See CMake upstream issue #22534.

Work around the CMake issue by ensuring that the path is properly
prefixed with a drive letter.

Pick-to: 6.2
Fixes: QTBUG-95652
Change-Id: I3154b6c0bb2f53533306227074b24fbbf5973b05
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-17 01:36:22 +00:00
Alexandru Croitor
6ef3d070a8 CMake: Replace usage of WIN32 with CMAKE_HOST_WIN32 in qconfig.cpp
The workaround of adding a drive letter to
QT_CONFIGURE_PREFIX_PATH_STR should be done when running on any
Windows host, not only when targeting Windows.

Amends 59c3be7117

Pick-to: 6.1 6.2
Task-number: QTBUG-87580
Change-Id: Ic6ca50aa58a4a54fb483e90fe61a907fe86cb002
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 03:36:22 +02:00
Martin Vejdarski
3c148323c0 CMake: Exclude dSYM INSTALL commands for already excluded tools in debug
Debug tools are excluded from the ALL target for debug_and_release
builds. However, when using the -separate-debug-info option, the same
exclusion wasn't being applied for their dSYM INSTALL commands,
resulting in a CMake install error.

Pass any additional install args like

  EXCLUDE_FROM_ALL COMPONENT "ExcludedExecutables"

to the installation rules of qt_enable_separate_debug_info and
install dSYMs for executables per-config in a multi-config build.

All the non-main config executable install rules are optional because
the non-main config executables are excluded from ALL.

Amends 5b136abd21

Pick-to: 6.2
Fixes: QTBUG-93999
Change-Id: I95c3ce28215c3ee535551e4b7a5fa9731f8f1c28
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 02:55:12 +02:00
Alexandru Croitor
48fa7f53cc CMake: Save QT_BUILD_BENCHMARKS and other info in BuildInternalsExtra
So that those values are used when configuring other repos in a
per-repo build arrangement.

Pick-to: 6.2
Change-Id: I5ff86260116c52afc87d7fcd5cbd047fcb9dde22
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 02:55:12 +02:00
Kai Köhne
d6661c5622 CMake: Warn if qt_internal_plugin(target) does not end with 'Plugin'
The logic for linking plugins in a static build in Qt6*Plugins.cmake
looks up plugins that are named Qt6*PluginConfig.cmake, and the file
name is computed by the target name.

Not naming the target 'Plugin' therefore means it won't be picked up
in static builds.

Pick-to: 6.2
Task-number: QTBUG-95731
Change-Id: Ic83a29d7c91492c302eb413a69577a0c550e1a1b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-12 12:43:49 +02:00
Alexey Edelev
f0bb95cb63 Use _qt_module_has_headers instead of INTERFACE_MODULE_HAS_HEADERS
After introducing the _qt_module_has_headers target property, it's
better to replace the INTERFACE_MODULE_HAS_HEADERS use by
_qt_module_has_headers since properties duplicate each other.

Pick-to: 6.2
Change-Id: I4d62ed71b8ed8263f51d8575628693122580b4a7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-08-11 21:39:53 +02:00
Alexandru Croitor
06c2400f5d CMake: Warn when using CMake 3.21.0 due to issue in AUTOMOC/AUTOUIC
There can be cases where trying to incrementally rebuild an already
built Qt will cause a ninja dependency cycle error due to incorrect
dependency information created by AUTOMOC and AUTOUIC.

Example error when building qtscxml tests

ninja: error: dependency cycle:
auto/scxmlcoutput/default/tst_scxmlcoutput_default_autogen/timestamp
->
auto/scxmlcoutput/default/ids1.h ->
auto/scxmlcoutput/default/tst_scxmlcoutput_default_autogen ->
auto/scxmlcoutput/default/CMakeFiles/tst_scxmlcoutput_default_autogen
->
auto/scxmlcoutput/default/tst_scxmlcoutput_default_autogen/timestamp

Example error when building Qt Creator

ninja: error: dependency cycle:
src/shared/help/shared_help_autogen/include/ui_filternamedialog.h ->
src/shared/help/shared_help_autogen/timestamp ->
src/shared/help/shared_help_autogen/include/ui_filternamedialog.h

Warn and advise to use a different CMake version instead.

Pick-to: 6.1 6.2
Change-Id: I6f529ba6a526663bc6ed699b1bfe8a9094129887
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-11 21:03:56 +02:00
Li Xinwei
1a8de144b6 Copy Find*.cmake to ${QT_BUILD_DIR}/lib/cmake/Qt6
In top-level builds, when configuring qtsensors, the directory of
FindWMF.cmake isn't in ${CMAKE_MODULE_PATH}, this makes CMake couldn't
find WMF.

On Windows, QtMultimedia requires WMF. If WMF couldn't be found,
QtMultimedia will also be treated as NOT FOUND.

QtSensors has an optional dependency to QtMultimedia. If QtMultimedia
couldn't be found, CMake will warn.

Copy Find*.cmake to ${QT_BUILD_DIR}/lib/cmake/Qt6, to make sure these
files could be found by CMake.

Fixes: QTBUG-95655
Pick-to: 6.2
Change-Id: I87d14c9a7becd0ec493e00c297b2e01fc0ad0f96
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-11 01:31:03 +08:00
Alexandru Croitor
dfabb5b677 CMake: Use __qt_internal_propagate_object_library for static plugins
Address TODO and use the new helper
__qt_internal_propagate_object_library function instead of
target_sources when linking static plugin initializers via usage
requirements.

Note that to work correctly this depends on using the
target_link_options object library linking approach, which means a
minimum CMake version of 3.17, which is already the case for static
Qt usage.
With CMake 3.21, it will use target_link_libraries approach instead.

With CMake version 3.16 or lower, currently, this won't work correctly
on Linux if there are dependencies wrapped in genexes because the
__qt_internal_propagate_object_library call will try to use
the still-by-default-enabled 'object_libraries' finalizer mode via
__qt_internal_collect_dependency_object_libraries and that stops
the usage of the target_sources approach to link the object files
directly.

This isn't a big deal though, because we already require CMake 3.20
as the minimum.
It might be a bigger deal if we will need any of this functionality
to work with 3.16 in shared Qt builds where the user project tries
to create and link against custom static plugins. But that's already
likely to be a can of worms even without this specific edge case.

Amends a37957df5c
Amends 91c65dd80c
Uses 3329212815

Pick-to: 6.2
Task-number: QTBUG-92933
Change-Id: I8710e79eee265d820f65c8ccc3d0bd0c0ee6eccd
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-10 16:51:53 +02:00
Alexandru Croitor
5161d8d525 CMake: Remove qt6_enable_object_libraries_finalizer_mode
qt6_enable_object_libraries_finalizer_mode is not needed anymore
now that static Qt builds require CMake 3.21 and thus CMake takes
care of placing object library object files at the beginning of
the link line.

Rename qt6_enable_import_plugins_finalizer_mode to a more generic
qt6_set_finalizer_mode that can enable or disable multiple
different modes.

For now the only available mode is "static_plugins" which handles
the behavior of the old function name.

The mode can be enabled by calling

 qt6_set_finalizer_mode(${target} ENABLE MODES "static_plugins")

Note that the function is re-tagged as being in Technical Preview.

Ideally we would not need it at all. But we need to provide some
workaround for the limitations of linking Qt static plugins in CMake
on Linux-y platforms that use bfd ld or ld.gold.

The workaround does not work well with dependencies wrapped in
generator expressions which is why we can't confidently advertise it
as a proper solution.
Our hope is that this can be fixed in future upstream CMake versions
and the function can be removed.
See 6fcc272ac9 for details.

Adjust the tests due to the renamed and removed functions.

Amends 19e789bace
Amends cdbb390c4a
Amends a25027eecb
Amends 6fcc272ac9
Amends a3c430f390

Pick-to: 6.2
Fixes: QTBUG-95169
Task-number: QTBUG-95601
Task-number: QTBUG-95603
Change-Id: I51b85f776ec29fc04fed1a637eba7d1f60609e69
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-10 16:51:53 +02:00
Alexandru Croitor
72a1e55472 CMake: Fix qt_find_package to work when CMP00126 is set to NEW
When CMP00126 is set to NEW, set(CACHE) doesn't remove regular
variable bindings with the same name as the cache variable.

This introduced an issue in qt_find_package, which called
find_package(CONFIG QUIET) to try and find a package config file, but
did not clean up the non-cache _FOUND variable which is automatically
set to 0 by CMake if no Config file is found.

Make sure to unset both the regular and cache _FOUND variables if either
the package config file was not found, or if none of the provided
targets found even if the Config file was found.

Also move the _DIR cache variable cleaning into the same code block.

Amends 4c31ce68d5
Amends 34b1c1c23c

Fixes: QTBUG-95635
Pick-to: 6.2
Change-Id: I871987217526e0f0a20038a8da52625838e49488
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-10 16:51:53 +02:00
Alexandru Croitor
eb22826057 CMake: Fix build with CMake master / 3.22
CMake master / 3.22 introduced a behavior change in how conditions are
evaluated in the while command. It is now consistent with how if()
evaluates conditions.

This caused an issue in Qt code where a "(" opening parenthesis was
evaluated as part of the condition rather than as a string.

Fix this by wrapping the evaluation of the variable in quotes.

Pick-to: 6.1 6.2
Change-Id: I70c26dc91394f4a14f7a26419df264a069dc7dc5
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Craig Scott <craig.scott@qt.io>
2021-08-10 12:05:31 +00:00
Joerg Bornemann
0e92ec9728 Remove dysfunctional -coverage configure argument
The -coverage argument merely added compiler flags for the Qt build.  It
was never properly ported to the CMake build, and it doesn't seem
feasible to have configure arguments for every possible compiler option.

The same can be achieved by passing the needed compiler option to CMake,
for example: CMAKE_CXX_FLAGS=-fsanitize-coverage=trace-pc-guard

Pick-to: 6.2
Fixes: QTBUG-86227
Change-Id: Ieef9acaedc0a839f9fb35b4403395eea28643864
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-10 12:00:13 +02:00
Alexandru Croitor
b2f00dfb46 CMake: Rename qt6_add_plugin TYPE option to PLUGIN_TYPE
The intention is to remove TYPE as a keyword completely before 6.2.0
release, but in case if that's not possible due to the large amount
of repositories and examples, just print a deprecation warning for
now and handle both TYPE and PLUGIN_TYPE.

Task-number: QTBUG-95170
Pick-to: 6.2
Change-Id: If0c18345483b9254b0fc21120229fcc2a2fbfbf5
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-06 21:08:21 +02:00
Alexandru Croitor
7d86cf02c1 CMake: Partially fix QUIETness of find_package(Qt6 COMPONENTS Foo)
When Qt5Config.cmake was ported to Qt6, the assignment of
_Qt6_FIND_PARTS_QUIET was accidentally left out.

Make sure that when find_package(Qt6 QUIET COMPONENTS Foo) is
called, the underlying component find_package(Qt6Foo) call gets
a QUIET option as well.

This will silence short-form warnings like

 -- Could NOT find Qt6Foo (missing: Qt6Foo_DIR)

It currently won't silence any warnings produced by the transitive
find_package calls in QtModuleDependencies.cmake. That will require a
separate change.

Remove usage of _Qt6_FIND_PARTS_REQUIRED which was always empty.
See details of QTBUG-95573 why it's currently not used.

Pick-to: 6.2
Task-number: QTBUG-95573
Change-Id: I3822c068eecbe84c306a1b04f4187278d35ec3d5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-06 17:00:21 +02:00
Alexandru Croitor
825cb50c27 CMake: Improve component / package not found error messages
Provide better error messages when a Qt package / component is not
found.

Mention the location of the expected Config file on the file system,
whether it exists
Also mention the location of the Config file that was specified by the
user when configuring the project or which CMake computed and stored
in QtModule_DIR cache var.

Mention that a package is not found in case if the main target exposed
by that package is not found.

If the target is not found, mention that it might be due to
QT_NO_CREATE_TARGETS being set to TRUE (when it is set to true).
If it is set to true, the assumption is that the target must have been
defined by something else before the find_package call (either an
earlier find_package call without QT_NO_CREATE_TARGETS set to TRUE or
maybe it's the use case of Qt being built together with its examples
or it's a super build).

Unset _Qt_NOTFOUND_MESSAGE to ensure that the Qt6 not found error
message is not spilled into any subsequent find_package(Qt6) calls,
causing a cascade of unwarranted warnings / errors.
Make sure to unset it only if components were specified, so the
message is not shown or unset in any of the recursive
find_package(Qt6) calls which is a dependency for regular Qt module
packages.
This works fine, because find_package(Qt6) calls with components are
only done in project code and not done by the transitive dependency
code (which looks for Qt6Foo packages directly).

Remove some dead code.

Pick-to: 6.2
Task-number: QTBUG-95532
Change-Id: Ie93d18e25e33aa0fe9e9da9a60e3d3e4cd6adb58
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-06 17:00:21 +02:00
Joerg Bornemann
fe9c705e9a CMake: Make qt6_wasm_add_target_helpers an internal function
This function is called by qt_add_executable.  There is no need to
expose it as public function.

Fixes: QTBUG-95172
Change-Id: I85a1d906ecda42458e226db225e47c1d348a72f1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-04 17:01:11 +02:00
Alexandru Croitor
6518bcc167 CMake: Enforce minimum CMake version in user projects
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>
2021-08-04 16:03:08 +02:00
Alexandru Croitor
9aa0d99e66 CMake: Bump min required CMake version for static Qt builds to 3.20
Building a static library Qt configuration will now require a
minimum CMake version of 3.20.

Qt builders and packagers can still opt out of the mentioned minimum
required version by configuring Qt with QT_FORCE_MIN_CMAKE_VERSION.
Such a Qt configuration is /NOT SUPPORTED/.

To facilitate these changes, the minimum version check has been moved
to happen after the BUILD_SHARED_LIBS option is computed by either
QtAutoDetect.cmake or set by a user provided cmake toolchain file.

Introduce a new QT_MIN_SUPPORTED_CMAKE_VERSION_FOR_STATIC_QT variable
in .cmake.conf to mark the minimum version for a static Qt build.

Pick-to: 6.2
Task-number: QTBUG-95018
Change-Id: Idc1875729f26a7c635b6bd26ac0c1be973917c13
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Craig Scott <craig.scott@qt.io>
2021-08-04 16:03:08 +02:00
Li Xinwei
a251443949 Avoid to call _qt_internal_set_up_static_runtime_library() twice
Pick-to: 6.2
Change-Id: I28985470b3e0b88befbbd2d62a027670d7d6c822
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-03 04:18:42 +08:00
Tor Arne Vestbø
7c14223b1e testlib: Update a few remaining instances of the deprecated -xunitxml format
The format was renamed in 27db9e458c.

Pick-to: 6.2
Change-Id: I53975c7467d8768dc9dc9ac2d89c42eefa12e22f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
2021-07-29 18:46:39 +02:00
Alexandru Croitor
3c23317552 CMake: Make WrapVulkanHeaders target optional for QtGui consumers
If Vulkan headers are present on the system when qtbase is configured,
QtGui and QtOpenGL should be compiled with Vulkan support.

If a user project uses a Qt built with Vulkan support, but their system
is missing Vulkan headers, the project configuration needs to succeed.

The project will get compilation errors if it uses Vulkan headers, but
that's intended.

This use case was broken when fixing Vulkan to be found when building
Qt for Android.

Fix the regression with a combination of things
1) Mark the WrapVulkanHeaders package as optional (already the case)
2) Use the include directories directly when compiling Gui and OpenGL
3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to
   consumers only if the target exists. It won't exist if Vulkan
   include dirs are not found

This also requires some changes in pri and prl file generation.

For prl file generation, we don't want to link to the
WrapVulkanHeaders target, so we filter out all dependencies that
use TARGET_NAME_IF_EXISTS for anything that calls
__qt_internal_walk_libs which includes qt_collect_libs.

For pri files, we make sure to generate a uses=vulkan/nolink clause
by inspecting a new _qt_is_nolink_target property on the target.

We also don't add include dirs to the pri file if the new
_qt_skip_include_dir_for_pri property is set.
This is intended for Vulkan, because there is separate qmake logic to
try and find the include dirs when configuring a user project.

As a drive-by, fix nolink handling for WrapOpenSSLHeaders.

Amends bb25536a3d
Amends 7b9904849f

Pick-to: 6.2
Fixes: QTBUG-95391
Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-29 16:38:50 +02:00
Alexandru Croitor
3b2157ed9e CMake: Fix MoltenVK headers to be found on macOS
This fixes building Qt with Vulkan support on macOS which aside from
the regular Vulkan headers also needs the location of the MoltenVK
headers.

This assumes the usage of the LunarG Vulkan SDK for macOS.

Pick-to: 6.2
Fixes: QTBUG-80576
Change-Id: I030b2fdeaafdd7bf5ebe6fb4c9ea860917e84056
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-29 16:38:49 +02:00
Alexandru Croitor
42970e490a CMake: Bump min required CMake version for shared Qt builds to 3.16
Building a shared library Qt configuration already required a minimum
CMake version of 3.16, because we depend on CMake's Autogen.json files
which are used for metatype.json file generation.

If a lower version was used, a FATAL_ERROR was issued in
qt6_extract_metatypes.

This change is essentially moving the check to happen earlier in the
qtbase configure process.

User projects will now /also/ officially require a minimum of 3.16
(up from 3.14).

As a consequence, the min/max version policy range that is set in
the public QtFooConfig.cmake files is changed
from 3.14..3.19
to   3.16..3.20

The upper bound is raised because building and using Qt works fine
with all CMake 3.20 policies set to NEW.

[ChangeLog][CMake] Building Qt as shared libraries now requires
CMake version 3.16 or later. Building user projects with CMake using
that Qt installation also requires a CMake version of 3.16 or later.

Pick-to: 6.2
Task-number: QTBUG-95018
Change-Id: I77d2829370f1dfc90b4071bebc8a3ade654e59e6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-07-28 20:54:14 +02:00
Jaeyoon Jung
c89a9ccbcc CMake: Keep public include header locations for internal module pri
Amends f254d62cb1.

Task-number: QTBUG-95303
Pick-to: 6.1 6.2
Change-Id: Ica8d2850fe427b780d62cd9a9528f387a7ea1b79
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-26 20:46:40 +09:00
Li Xinwei
bd594f9457 CMake: Use namespaced variables in Qt6*Dependencies.cmake
Pick-to: 6.2 6.1
Change-Id: I166988020cfd9750a4d58e519742215d0c03ad3e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-24 03:51:53 +08:00
Li Xinwei
2915921ad2 Fix generated pri and prl files
Quote the paths after "-L".

Get MSVC’s implicit link directories from $ENV{LIB}.

Fix some issues cause by Inconsistent case.

Amends 2c49f85380

Fixes: QTBUG-95198
Pick-to: 6.2 6.1
Change-Id: Ie82f10b088e2764396377726340509f24a4ae8e7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-17 02:42:13 +08:00
Alexandru Croitor
fb9cbd3b2a CMake: Clean up and simplify qt6_extract_metatypes implementation
Remove copying of json files in non-prefix builds.
Previously, this was done to mimic the directory layout of prefix
builds in a non-prefix build, but the extra complexity is not worth
it.
Keeping the files in the build directories of each repo in a
non-prefix build should be good enough.

As a result, we don't need to distinguish which file path should be
passed in INTERFACE_SOURCES. Now we have only 2 paths to consider, the
BUILD_INTERFACE one and the INSTALL_PREFIX one, rather than 3
different paths.

Move the code that handles installation closer together.

Rename the internal COPY_OVER_INSTALL option to
___QT_INTERNAL_NO_INSTALL.
We might want to expose it as a public option later, but it depends on
whether we will disable default installation for user projects.

Remove assignment of some properties that are not used anymore.

Amends c431e2d33c

Pick-to: 6.2
Task-number: QTBUG-94942
Change-Id: I3a26d1988987b2ce7c7d01d2311c13b3da3175a8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-16 18:19:19 +02:00
Alexandru Croitor
e0a0101290 CMake: Apply bitcode flags to internal plugin object lib initializers
All internal libraries, plugins, object libraries (resources, plugin
initializers) need to be built with bitcode flags when targeting iOS.

Internal here means all libraries added by qt_internal_add_X
functions or associated with internal libraries.

We didn't do that for plugin initializers, which were added not too
long ago.

Extract the logic that links to Qt::PlatformModuleInternal into a
separate function to be used for object libraries.
Use it for resources and plugin initializers. It will also be used
in qtdeclarative for qml plugin initializers.

Pick-to: 6.2
Task-number: QTBUG-95208
Change-Id: I366996078f5e9d1c2d2797f6b81c522ee99529e3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-16 09:52:26 +02:00
Alexandru Croitor
3595613a0a CMake: Don't propagate -fapplication-extension to user projects
Both the compiler and linker -fapplication-extension flag should only
be applied when building Qt's libraries (not executables).

It's up to the user project whether their code will be restricted with
application-extension-only APIs.

In qmake that can be achieved by adding to the qmake project
  CONFIG += app_extension_api_only

In CMake it can be achieved by either adding the compiler and link flags
in the project directly (using target_X_options) or by setting the
appropriate setting in the Xcode project when using the Xcode
generator.

Amends e189126f1a

Pick-to: 6.2
Task-number: QTBUG-95199
Change-Id: Ie7a764d460a89c7650391abff0fcc5abfcabef64
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-16 09:52:24 +02:00
Alexandru Croitor
616c32be04 CMake: Fix bitcode linker flags not to be added on iOS
We shouldn't force add the bitcode linker flags to user projects.
And we don't link anything when building Qt for iOS itself, we only
archive object files into static libraries.

The final decision whether bitcode should be used is up to the Xcode
project. That is controlled by Xcode's ENABLE_BITCODE option.

Bitcode compile flags are still added when building Qt itself.

Amends a046833176

Pick-to: 6.1 6.2
Task-number: QTBUG-95199
Change-Id: I04c77f659b82269bb8010ea262b2e51f36e9def3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-16 09:52:21 +02:00
Alexandru Croitor
ba0d5ab555 CMake: Force Integrity to be a static Qt build
This was the case in Qt 5.15 as well.

The CMake toolchain file that Qt's CI is using is already setting
BUILD_SHARED_LIBS to OFF, but it's better to be explicit like we
are with WebAssembly and iOS.

Pick-to: 6.2
Change-Id: Ief17259c15690a97337e9df451663718601c2a52
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-15 17:12:57 +02:00
Allan Sandfeld Jensen
f3e006a698 Report multi-arch targets in the configure summary
Otherwise it will confusingly only list the host arch

Pick-to: 6.2
Change-Id: Ic6d080f1fd9ebfa260ce7c35bd5e5b4ee686f083
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-14 20:59:09 +02:00
Li Xinwei
c9db5eed54 fix wrong argument
amends 5b136abd21

Pick-to: 6.2
Change-Id: I8dee597c4ba41ecd07289b724f5e2b52ba705a9f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-14 23:56:01 +08:00
Alexandru Croitor
b5a0f88029 CMake: Fix IMPORTED_IMPLIB to be set for shared libraries on Windows
The correct variable to check is WIN32, not WINDOWS.

Amends 85e25d93b3

Pick-to: 6.2
Change-Id: I4570eb5a124bcaa0bd38135dd7c7f48345c40c9d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2021-07-14 17:14:24 +02:00
Alexey Edelev
0ae2537ad4 Use module interface name as OUTPUT_NAME
For internal modules we should keep the name of the file in file system
consistent with previous Qt versions.

Pick-to: 6.2
Fixes: QTBUG-95077
Change-Id: I02e4fced0fc3172e60f07bc7d1515e23744db567
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-13 20:15:14 +02:00
Joerg Bornemann
564f07086c Don't repeat conditions of use_*_linker features in QtFeature.cmake
qt_config_linker_supports() repeated the conditions of all use_*_linker
features, because the features are not evaluated yet when this function
is called, and the function needs to know what linker is used to build Qt.

Move the required tests and features before any
qt_config_linker_supports() call and evaluate the use_*_linker features
early.

Change-Id: I306f032356682a0e82e4d7c4234e5bbc820ab143
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-13 15:27:23 +02:00
Alexey Edelev
adfb767bcc Move the logic associated with platform definition directory
Since platform definition directory is used as an interface include
path of the Qt::Platform target, it makes sense to define it for this
target only. Also the definition of cached values that contain
path to platform definition looks redundand.

The definition of QT_PLATFORM_DEFINITION_DIR from command line
doesn't make any sense since build procedure doesn't take it into
account when installing mkspecs and the use if the user-provided
QT_PLATFORM_DEFINITION_DIR value as a Qt::Platform include directory
causes inconsistency in the prefixed builds. INSTALL_MKSPECSDIR
and QT_QMAKE_TARGET_MKSPEC should be used instead.

Change-Id: I3636c57b835cb84511a358a0910cc482c5fbd81e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-13 14:31:16 +02:00
Joerg Bornemann
8ac8d812f7 Warn on any PUBLIC usage requirements specified for Qt plugins
Repositories have been changed to be free of this warning. We're now
changing the default of QT_WARN_PLUGIN_PUBLIC_KEYWORDS to ON.

Set this variable to OFF to disable the warnings.

Pick-to: 6.2
Change-Id: Ie37a4df1032f5b1e9152d970e8a14c574ed70241
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-12 19:49:13 +02:00
Alexandru Croitor
451733bd57 CMake: Fix reconfiguration error when features have EMIT_IF conditions
Previously, if a feature was marked as not to be emitted and there was
no user provided value for that feature, the build system would still
save the user provided value in FEATURE_foo with a value of ON (if the
conditions were met).

After a reconfiguration, the build system would hit the code path that
checks if the user provided a value for the non-emitted feature, and
would then warn about it and reset the feature value to OFF.

This would cause errors when reconfiguring a user project, complaining
that a feature value has changed.

Make sure to not save the user provided value for a non-emitted
feature and to always set its internal feature value to OFF.

Amends c4f5762b20

Pick-to: 6.2
Fixes: QTBUG-94921
Change-Id: I257c7fd795c8a6aeba3348cb72522e4f0b006dc9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-09 12:44:35 +02:00
Alexandru Croitor
cde126ef26 CMake: Rename and document the feature evaluation functions
Rename various functions and variables to hopefully make the behavior
of feature evaluation clearer.

The previous names like 'set_value' or 'set_cache_value' or 'cache'
were too generic and unclear. One would have to carefully read the
code to understand what was actually set.

Add some doc comments about what FEATURE_foo and QT_FEATURE_foo
represent.

Amends c4f5762b20

Pick-to: 6.2
Task-number: QTBUG-94921
Change-Id: Ie6a7b83a4d54a83976b2706d4af82b39832d79f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-09 12:44:35 +02:00
Alexandru Croitor
51ae235080 CMake: Use correct MSVC runtime library for Qt object libraries
If Qt was configured with -static-runtime which implies MultiThreaded
-MT flag, the plugin initializer object libraries were still compiled
with the default -MD flag.

When an application linked to Qt, that caused linking to fail with
mismatched symbol errors between the application symbols and the
plugin initializer object library symbols.

Make sure to set the MSVC_RUNTIME_LIBRARY property on both plugin
initializer and resource object libraries, depending on the value of
QT_FEATURE_static_runtime.

We did set the property for resources added by
qt_internal_add_resource, but not for the resource created by
the public qt6_add_resources counterpart.

Pick-to: 6.2
Fixes: QTBUG-95043
Change-Id: Ia543cd0241db94a12080be2655ad420fe9ad3f24
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-09 12:44:35 +02:00
Alexandru Croitor
7b3d9efc04 CMake: Place internal apps in the correct output directory
In a -debug-and-release build, apps were placed under bin/Release
rather than just bin.

Apply the logic we use for tools for apps as well. Rename and move
the common functions into QtTargetHelpers.cmake.

Pick-to: 6.2
Fixes: QTBUG-95028
Change-Id: I5a9082ea50c9238c8fcf0c6dd099708fbc571bf8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-09 09:44:58 +02:00
Alexey Edelev
f33d11796f Hide QT_USE_BUNDLED_ CACHE variables from GUI
Make QT_USE_BUNDLED_ INTERNAL to hide them from GUI like QtCreator's
CMake configurator.

Pick-to: 6.1 6.2
Change-Id: Id9dcee31c69b579bbe38611cabb98e46550b0e89
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 23:38:25 +02:00
Alexey Edelev
b2649754f1 Make QT_HAVE_LINK_ORDER_MATTERS INTERNAL to hide from GUI
Hide QT_HAVE_LINK_ORDER_MATTERS from GUI like QtCreator's CMake
configurator.

Pick-to: 6.1 6.2
Change-Id: I9591092f0902ad17ff260a1ca4494239a7acf6fa
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 23:38:25 +02:00
Joerg Bornemann
85e25d93b3 CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only
In our *AdditionalTargetInfo.cmake we now set above target properties
for shared libs only, not executables.

IMPORTED_IMPLIB is only set for Windows.
IMPORTED_SONAME is only set for non-Windows platforms.

Pick-to: 6.2
Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 16:40:35 +02:00
Joerg Bornemann
7540b4bd56 Fix build of Debug projects against debug-and-release non-prefix Qt
Building a CMake project with CMAKE_BUILD_CONFIG=Debug was broken for
non-prefix debug-and-release builds of Qt.

In debug-and-release builds we set EXCLUDE_FROM_ALL on tools in the
Debug configuration. In non-prefix builds we export(EXPORT) targets, and
that also contains the non-existent Debug variants of the tools.  In
prefix builds, we install(EXPORT) instead, which only exports what is
built and installed.

Consequently, we now remove the DEBUG-related import information if the
debug variant if the target binary does not exist.

Pick-to: 6.2
Fixes: QTBUG-95027
Change-Id: I37766d5ab1e2795bcb91a348e7e72150e8a00f82
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 16:40:35 +02:00
Andreas Buhr
3818046204 fix warning in cborparser with gcc 11.1
Pick-to: 6.2
Change-Id: Ie8270f2b156b194dedd115a97b93f7f800af055e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2021-07-07 22:07:13 +02:00
Alexey Edelev
9bbca531eb Fix platform definition directory in top-level build
QT_BUILD_DIR should be used instead of CMAKE_BINARY_DIR as a base
directory for platform definition when building a non-prefixed
build since artifacts are copied to qtbase directory for top-level
build.

Amends 478f5fcde6

Pick-to: 6.1 6.2
Task-number: QTBUG-94973
Change-Id: I5cce16fdc7f760b954222ae67a4b85d4beea7f13
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-07 17:07:15 +02:00
Craig Scott
9e05e25acf CMake: Fix typo in function name
Pick-to: 6.2
Change-Id: I72ab657670ca6fa460b3495f85d6edd920ee2c8a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-07 17:40:45 +10:00
Joerg Bornemann
46d2ba1ea4 Restore default installation prefix from Qt 5
Change the default installation prefix to C:/Qt/Qt-${version} on Windows
and /usr/local/Qt-${version} elsewhere.

This is what's expected by users coming from Qt5, and setting the
installation prefix to "/usr/local" manually is easier than setting the
versioned variant "/usr/local/Qt-6.2.0".

[ChangeLog][Build System] The installation prefix now defaults to
/usr/local/Qt-${version} and C:/Qt/Qt-${version} like it did in Qt 5.

Fixes: QTBUG-91632
Pick-to: 6.2
Change-Id: I8ce57b1b18084c705b194c776e038cc807a6ed5e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-06 16:52:58 +02:00
Joerg Bornemann
d9a9eca54d Remove unsupported host-related configure options
The following host-related configure options were unsupported since Qt
6.0 and are now completely removed:
-hostprefix
-external-hostbindir
-host*dir (except -hostdatadir)
-android-ndk-host

Pick-to: 6.2
Change-Id: Ib69d90c40ef546f61bf87b1f443eb9d10f7a5a21
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-06 08:53:52 +02:00
Joerg Bornemann
16e869bd01 Remove outdated information from configure-cmake-mapping.md
Pick-to: 6.2
Change-Id: I5101a3d7d07e4c0e818fb005707d99c6afe8f589
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-06 08:53:44 +02:00
Alexey Edelev
478f5fcde6 Fix the detection of platform definitions directory
Platform definition directory is defined when building qtbase.
Depending on the build type (prefixed/non-prefixed) it should point:
  - To the source directory when building prefixed qtbase.
  - To the installation directory of the prefixed qtbase when building
consumer projects.
  - To the build directory of non-prefixed qtbase when building
non-prefixed qtbase or consumer projects.

TODO: It is desirable to move the logic asssociated with Qt platform
definition to the qt_internal_setup_public_platform_target function.

Pick-to: 6.1 6.2
Fixes: QTBUG-94973
Change-Id: I8530613f9b2029834c66206bbdf02475528a4640
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-05 22:00:01 +02:00
Joerg Bornemann
6fec7eae31 Make Android detection more robust
Our only way to detect whether the user requests an Android build of Qt
was to peek into the CMake toolchain file if it is specified.  If the
toolchain file contains a certain magic string, we decide that we're
building for Android.

This approach is fragile and bound to break should the Android toolchain
file's magic string ever change.

Now, we assume an Android build if any of our ANDROID_* cache variables
is set. In that case, we do not peek into the toolchain file.

Pick-to: 6.2
Fixes: QTBUG-94955
Change-Id: Ie2f0ac0963f90f09805e311111bb6912d4325ada
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-05 17:11:22 +02:00
Joerg Bornemann
5bd7952e96 Fix typo in function name qt_auto_detect_vcpkg
Pick-to: 6.2
Change-Id: Ie0fd74a9e1faf8dc55faac1940d100af72cf8030
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-02 18:22:16 +02:00
Alexey Edelev
e80b010795 Use target_link_options to propagate object libraries
target_link_options are placed by CMake at the beginning of a linker
line. This gives us an opportunity to use the function to propagate
object libraries. This change adds one more check in the root
Config.cmake file. If CMP0099 policy is enabled, CMake enables
propagating of the linking options when linking two static libraries
using the PRIVATE linking visibility, so we can rely on the correct
linking order and expect object libraries to be propagated.

Note that on the platforms where cmake version is higher than 3.16
Qt uses CMP0099 NEW in functions like qt_add_executable. This means
that at the moment of creating an executable target the TARGET_POLICY
genex will also be NEW, so we do not take into the account the user
defined CMP0099.

If the CMP0099 policy is not available for a certain CMake version
we skip the TARGET_POLICY check and simply disable propagation of
the object libraries using target_link_options for both user and Qt
libraries. This is applicable for the CMake versions 3.16 and less.

Linking approaches have the following priorities(from higher to lower)
after this change:
  - target_link_libraries - works if link order matters not or CMake
    version greater equal 3.21.
  - target_link_options - works if CMP0099 is set to NEW by user or
    if the CMake version is greater than or equal to 3.17 and an
    executable is created using Qt functions.
  - object library finalizer - works if CMake version is greater equal
    3.19 or qt6_finalize_target is called explicitly.
  - target_sources - is used when all the other approaches could not
    be used.

Amends a1fd4f51ad
Amends 3329212815

Pick-to: 6.2
Change-Id: I14f88caeb04e357191c840abeab89b03e210b796
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-02 15:17:06 +02:00
Joerg Bornemann
c72b7b8e5e Revert "Make toolchain inspection more robust"
This reverts commit 7c62caa355.

Certain toolchain files cannot be read in CMake script mode with CMake
versions >= 3.20.

For example, the vcpkg toolchain file overrides add_executable, and
that fails with CMake 3.20:
CMake Error at D:/dev_tools/vcpkg/scripts/buildsystems/vcpkg.cmake:662 (function):
 Built-in flow control command "add_executable" cannot be overridden.

Pick-to: 6.2
Fixes: QTBUG-93627
Change-Id: Ib6e6352dff50b9684dcf81401d138e27e16292c3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-02 15:05:32 +02:00
Alexandru Croitor
bb25536a3d CMake: Fix Vulkan to be found when targeting Android
Introduce two new packages WrapVulkanHeaders and WrapVulkan similar to
the OpenSSL wrapper packages.

WrapVulkanHeaders uses FindVulkan and is marked as found if Vulkan
headers are found (that's the only part the Qt build requires).

The WrapVulkan package is currently not used, but is there for
symmetry.

The Vulkan feature is now disabled by default on QNX, because the
QNX toolchain file in the CI does not set
CMAKE_FIND_ROOT_PATH_MODE-like variables and CMake ends up finding
host Vulkan headers causing the build to break.

Pick-to: 6.2
Fixes: QTBUG-92157
Change-Id: I05309821f866456cd42e7f85bf8b76ba099df656
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-01 18:57:50 +02:00
Alexandru Croitor
6d59e1e088 CMake: Be more explicit about found OpenSSL variables
Specifying the variables as required variable will show the found
paths in the configure output.

Pick-to: 6.2
Task-number: QTBUG-94355
Change-Id: I985a3585f37b38e25b6be4fae5d42c82e06517de
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-01 18:57:22 +02:00
Alexandru Croitor
82063d9af1 CMake: Pierce through LINK_ONLY deps in finalizer dep traversal
Ensure that the finalizer approach of
__qt_internal_propagate_object_library considers $<LINK_ONLY:>
libraries when traversing the dependencies of a target.

The issue was discovered when using the Quick.Shapes QML module in a
static build. The module has both a backing library and a plugin.
The backing library has some resource objects associated with it.
When the targets are exported, the plugin INTERFACE_LINK_LIBRARIES
has a $<LINK_ONLY:QuickShapes> dependency.

This ensures that the library will be linked, but depending on which
linking approach in __qt_internal_propagate_object_library is used,
the resources might not be linked to the final executable.

The resources are linked correctly when using the
target_link_libraries approach, but not when using the finalizer or
target_sources approach.

This change fixes the finalizer approach, but the target_sources
approach is still broken.

Amends a1fd4f51ad

Pick-to: 6.2
Change-Id: Ifbb91a17d388c3dc4263e17ec0d3bd5627b57cb4
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-29 17:03:28 +02:00
Alexey Edelev
dec84a56f5 Throw FATAL_ERROR if specified platform doesn't exist
If user specifies non-existing platform build fails in some non-obvious
place, since qplatfromdefs.h couldn't be found.

Add an explicit error if the defined platform folder doesn't exists in
Qt sources.

Change-Id: Id847d57a6f9cc4f463e697b474b8a669cd041fb8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-25 13:32:26 +02:00
Alexandru Croitor
e2c6f2ba7e CMake: Fix 'Cannot find source file' error with older CMakes
Configuring a static qtdeclarative with CMake versions older than
3.18.0 fails at generation phase with

CMake Error at cmake/QtExecutableHelpers.cmake:28 (add_executable):
  Cannot find source file:

   some_path/some_target_plugin_imports_Gui.cpp

Marking the generated file as GENERATED explicitly solves the issue.

Pick-to: 6.1 6.2
Change-Id: Ife0eba61a1aab4f988d9fe7e2217d30eb96774a7
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-25 12:33:58 +02:00
Alexandru Croitor
1981682687 CMake: Propagate sanitizer flags to public projects
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>
2021-06-25 12:33:58 +02:00
Alexandru Croitor
9a9da3aad2 CMake: Handle fuzzer-no-link sanitizer feature name correctly
Pick-to: 6.2
Task-number: QTBUG-87989
Change-Id: Ife42f1fe001c5fafd10981f23dcd387cacc15276
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-25 12:33:58 +02:00
Alexandru Croitor
8c1a35a991 CMake: Restore Qt-custom sanitizer additions to ECMEnableSanitizers
Restores addition of 'float-divide-by-zero' to undefined sanitizer
flags as well as the custom fuzzer-no-link option.

Pick-to: 6.2
Task-number: QTBUG-87989
Change-Id: Icde1e5d31083ce1b6128ab45b0e9df5ae69736a3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-25 12:33:58 +02:00
Alexandru Croitor
6b3e512e02 CMake: Update ECM sanitizer module to latest version
To bring support for sanitizers when using MSVC.

Pick-to: 6.2
Task-number: QTBUG-87989
Change-Id: I7a8ebf8fdaa31669df82d232fd9eae4e72407b92
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-25 12:33:58 +02:00
Alexey Edelev
9bd418aeab Implement generating of a module cpp export header
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>
2021-06-24 20:40:49 +02:00
Alexey Edelev
1cb63fcc97 Disable forced full optimization if QT_USE_DEFAULT_CMAKE_OPTIMIZATION_FLAGS=ON
Pick-to: 6.2
Task-number: QTBUG-94753
Change-Id: Ib9dda1a96f3123394e3b3d4f84feac8cedd18b89
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-24 18:10:32 +02:00
Joerg Bornemann
d6e01ae05c Fix QT_HOST_DATA for builds setting INSTALL_MKSPECSDIR
In a Qt build that was configured with INSTALL_MKSPECSDIR set to
something different than INSTALL_DATADIR, the qmake property
QT_HOST_DATA was wrong. Consequently, mkspecs could not be loaded,
rendering qmake dysfunctional.

The reason was that we considered every QT_HOST_xxx property to have the
same value as QT_INSTALL_xxx in a non-cross build.
This is not true for QT_HOST_DATA, because users might want to set
INSTALL_DATADIR to "foo" but INSTALL_MKSPECSDIR to "bar/mkspecs".

Move the unused determination of the host data dir to the QtLibraryInfo
lib and handle QT_HOST_DATA specially.

Fixes: QTBUG-94591
Pick-to: 6.2
Change-Id: I2c44cda8405ff1d14391254fcd1d9b1361cb5855
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-23 22:12:41 +02:00
Kai Köhne
d0676874d6 MSVC: Enable warnings-are-errors for latest Visual Studio 2019
Also remove handling of older versions, because we only support
Visual Studio 2019 currently

Pick-to: 6.2
Change-Id: If66a46d970047fe25582e323df74e0a904ee92da
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2021-06-23 12:49:19 +02:00
Morten Sørvig
53eb44906c wasm: don’t set exit_runtime
Go with Emscripten’s default of not shutting down on
main() exit; this allows for writing main() in such
a way that avoids the exec() workaround.

Existing main() implementations (which do use the exec()
workaround) do not shut down Qt cleanly anyway, so we
gain little by shutting down the Emscripten runtime.

Applications can set this flag if they do want to shut
down on main() exit:
    LFAGS += -s EXIT_RUNTIME=1

Change-Id: I52e1cc2bc907d1d2146822713e39b7610db3f95b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
2021-06-23 06:57:21 +00:00
Giuseppe D'Angelo
648e9696d3 Disable -Werror=stringop-overflow on GCC >= 10
There's a number of upstream bugs that cause false positives;
do not make them errors.

Change-Id: I4151794d8d37177a47a34aef8d83accf4377d44a
Pick-to: 6.1 6.2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2021-06-23 00:23:55 +02:00