The variable might be defined to HOST_PERL-NOTFOUND which will return
early instead of issuing an error.
Change-Id: Id49dfd0fec8f477dad9e816e6128e36059e68702
Pick-to: 6.2
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We default to configuring examples as separate ExternalProjects when
using a developer / non-prefix Qt build.
This ensures we test that the examples configure successfully without
the pollution of the main Qt build (e.g. already found packages).
One down-side of this is that a developer's IDE doesn't see these
example targets, unless each project is loaded into the IDE
separately. This is cumbersome to do when refactoring or renaming
code across multiple example projects.
Allow configuring the example projects as part of the main Qt build
by setting QT_BUILD_EXAMPLES_AS_EXTERNAL to FALSE when configuring Qt.
Save the value of the variable in QtBuildInternalsExtra.cmake.in
so it's propagated to leaf repositories as well.
Amends dab8f64b6d
Amends d97fd7af2b
Task-number: QTBUG-90820
Task-number: QTBUG-94608
Task-number: QTBUG-96232
Task-number: QTCREATORBUG-26168
Pick-to: 6.2
Change-Id: Ie1f724f74365b3a788b04c3fffe9eb2d0611dd50
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
There is no need for this variable to be stored in CMake's cache. We
don't perform expensive operations to set up QT_SYNCQT, and we even
unset the cache variable to ensure it gets recomputed on
reconfiguration.
We still store QT_SYNCQT in a global property, because the function
qt_ensure_sync_qt is called in different directory scopes, and we want
to avoid re-calculations for every subdir.
It's now possible for the user to set QT_SYNCQT (see QTBUG-88088 for
motivation). Also, in a non-prefix build, changes to syncqt.pl in the
source dir are reflected upon re-configuration in the build
tree (because qt_copy_or_install is called on every configure).
Pick-to: 6.2
Fixes: QTBUG-88088
Task-number: QTBUG-75290
Change-Id: I6137b060d200d3dafd4a64d5a6c1bd2549723d78
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
_<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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
The format was renamed in 27db9e458c.
Pick-to: 6.2
Change-Id: I53975c7467d8768dc9dc9ac2d89c42eefa12e22f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Otherwise it will confusingly only list the host arch
Pick-to: 6.2
Change-Id: Ic6d080f1fd9ebfa260ce7c35bd5e5b4ee686f083
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
