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>
