AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
97a7e7b2d0
qt5base-lts/cmake/QtPluginHelpers.cmake

594 lines
26 KiB
CMake
Raw Normal View History

Add license headers to cmake files CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-05 11:26:52 +00:00
# Copyright (C) 2022 The Qt Company Ltd.
Change the license of all CMakeLists.txt and *.cmake files to BSD Task-number: QTBUG-105718 Change-Id: I5d3ef70a31235868b9be6cb479b7621bf2a8ba39 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-08-19 13:21:34 +00:00
# SPDX-License-Identifier: BSD-3-Clause
Add license headers to cmake files CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-05 11:26:52 +00:00
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
# Note that these are only the keywords that are unique to qt_internal_add_plugin().
# That function also supports the keywords defined by _qt_internal_get_add_plugin_keywords().
macro(qt_internal_get_internal_add_plugin_keywords option_args single_args multi_args)
set(${option_args}
EXCEPTIONS
ALLOW_UNDEFINED_SYMBOLS
SKIP_INSTALL
)
set(${single_args}
OUTPUT_DIRECTORY
INSTALL_DIRECTORY
ARCHIVE_INSTALL_DIRECTORY
${__default_target_info_args}
)
set(${multi_args}
${__default_private_args}
${__default_public_args}
DEFAULT_IF
)
endmacro()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
# This is the main entry point for defining Qt plugins.
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-06-04 06:32:33 +00:00
# A CMake target is created with the given target.
# The target name should end with "Plugin" so static plugins are linked automatically.
# The PLUGIN_TYPE parameter is needed to place the plugin into the correct plugins/ sub-directory.
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
function(qt_internal_add_plugin target)
qt_internal_set_qt_known_plugins("${QT_KNOWN_PLUGINS}" "${target}")
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
_qt_internal_get_add_plugin_keywords(
public_option_args
public_single_args
public_multi_args
)
qt_internal_get_internal_add_plugin_keywords(
internal_option_args
internal_single_args
internal_multi_args
)
set(option_args ${public_option_args} ${internal_option_args})
set(single_args ${public_single_args} ${internal_single_args})
set(multi_args ${public_multi_args} ${internal_multi_args})
Retire the qt_parse_all_arguments This replaces the qt_parse_all_arguments macro with the built-in `cmake_parse_arguments(PARSE_ARGV`. In addition, a new function, _qt_internal_validate_all_args_are_parsed, can be used to check whether any _UNPARSED_ARGUMENTS have been passed to the function. Fixes: QTBUG-99238 Change-Id: I8cee83dc92dc6acdaaf747ea6ff9084c11dc649b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-11 14:36:18 +00:00
cmake_parse_arguments(PARSE_ARGV 1 arg
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
"${option_args}"
"${single_args}"
"${multi_args}"
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
)
Retire the qt_parse_all_arguments This replaces the qt_parse_all_arguments macro with the built-in `cmake_parse_arguments(PARSE_ARGV`. In addition, a new function, _qt_internal_validate_all_args_are_parsed, can be used to check whether any _UNPARSED_ARGUMENTS have been passed to the function. Fixes: QTBUG-99238 Change-Id: I8cee83dc92dc6acdaaf747ea6ff9084c11dc649b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-11 14:36:18 +00:00
_qt_internal_validate_all_args_are_parsed(arg)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
cmake: Don't give plugins PUBLIC usage requirements The pro2cmake.py conversion script faithfully reproduced the .pro files for the plugins, which specified the libraries as public. But in CMake, the implications of this are that public usage requirements should then be propagated to consumers. We don't expect any consumers, since a plugin is created as a MODULE library in CMake, so for Windows we don't even have an import library to link with. The only exception to this is for static builds where plugins are created as STATIC libraries instead, but only in certain controlled situations do we then link to plugins. Even then, usage requirements are not expected to propagate to the consumers, so these relationships should always be specified as private. This change warns on any PUBLIC usage requirements specified for a plugin. This check is disabled by default to avoid spamming CI builds for repos that haven't been fixed yet. The check can be enabled by a CMake cache option, which is intended for developers to use locally when fixing this issue in other repos (all plugins in qtbase should not trigger this warning as a result of changes in this commit). Task-number: QTBUG-90819 Pick-to: 6.1 Change-Id: I09f2c8da77db1193ad3370f85d367dfc6ab7b9a6 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-02-10 01:11:39 +00:00
# Put this behind a cache option for now. It's too noisy for general use
# until most repos are updated.
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-09 11:07:25 +00:00
option(QT_WARN_PLUGIN_PUBLIC_KEYWORDS "Warn if a plugin specifies a PUBLIC keyword" ON)
cmake: Don't give plugins PUBLIC usage requirements The pro2cmake.py conversion script faithfully reproduced the .pro files for the plugins, which specified the libraries as public. But in CMake, the implications of this are that public usage requirements should then be propagated to consumers. We don't expect any consumers, since a plugin is created as a MODULE library in CMake, so for Windows we don't even have an import library to link with. The only exception to this is for static builds where plugins are created as STATIC libraries instead, but only in certain controlled situations do we then link to plugins. Even then, usage requirements are not expected to propagate to the consumers, so these relationships should always be specified as private. This change warns on any PUBLIC usage requirements specified for a plugin. This check is disabled by default to avoid spamming CI builds for repos that haven't been fixed yet. The check can be enabled by a CMake cache option, which is intended for developers to use locally when fixing this issue in other repos (all plugins in qtbase should not trigger this warning as a result of changes in this commit). Task-number: QTBUG-90819 Pick-to: 6.1 Change-Id: I09f2c8da77db1193ad3370f85d367dfc6ab7b9a6 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-02-10 01:11:39 +00:00
if(QT_WARN_PLUGIN_PUBLIC_KEYWORDS)
foreach(publicKeyword IN LISTS __default_public_args)
if(NOT "${arg_${publicKeyword}}" STREQUAL "")
string(REPLACE "PUBLIC_" "" privateKeyword "${publicKeyword}")
message(AUTHOR_WARNING
"Plugins are not intended to be linked to. "
"They should not have any public properties, but ${target} "
"sets ${publicKeyword} to the following value:\n"
" ${arg_${publicKeyword}}\n"
"Update your project to use ${privateKeyword} instead.\n")
endif()
endforeach()
endif()
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
qt_remove_args(plugin_args
ARGS_TO_REMOVE
${internal_option_args}
${internal_single_args}
${internal_multi_args}
ALL_ARGS
${option_args}
${single_args}
${multi_args}
ARGS
${ARGN}
)
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 91c65dd80cdd2de666448c14202c0c63718152b6 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 4caac1feea025b0ad496141e8f16ab88c04c2caa 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-19 09:42:12 +00:00
# When creating a static plugin, retrieve the plugin initializer target name, but don't
# automatically propagate the plugin initializer.
list(APPEND plugin_args
__QT_INTERNAL_NO_PROPAGATE_PLUGIN_INITIALIZER
OUTPUT_TARGETS plugin_init_target
)
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
qt6_add_plugin(${target} ${plugin_args})
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 e189126f1ae1d2fa2ad0f95ee2c4aa72c770a97b 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-15 11:04:15 +00:00
qt_internal_mark_as_internal_library(${target})
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
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-04 14:18:44 +00:00
set(plugin_type "")
# TODO: Transitional: Remove the TYPE option handling after all repos have been converted to use
# PLUGIN_TYPE.
if(arg_TYPE)
set(plugin_type "${arg_TYPE}")
elseif(arg_PLUGIN_TYPE)
set(plugin_type "${arg_PLUGIN_TYPE}")
endif()
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-06-04 06:32:33 +00:00
if((NOT plugin_type STREQUAL "qml_plugin") AND (NOT target MATCHES "(.*)Plugin$"))
message(AUTHOR_WARNING "The internal plugin target name '${target}' should end with the 'Plugin' suffix.")
endif()
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-04 14:18:44 +00:00
qt_get_sanitized_plugin_type("${plugin_type}" plugin_type_escaped)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
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-04 14:18:44 +00:00
set(output_directory_default "${QT_BUILD_DIR}/${INSTALL_PLUGINSDIR}/${plugin_type}")
set(install_directory_default "${INSTALL_PLUGINSDIR}/${plugin_type}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
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-04 14:18:44 +00:00
qt_internal_check_directory_or_type(OUTPUT_DIRECTORY "${arg_OUTPUT_DIRECTORY}" "${plugin_type}"
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
"${output_directory_default}" output_directory)
if (NOT arg_SKIP_INSTALL)
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-04 14:18:44 +00:00
qt_internal_check_directory_or_type(INSTALL_DIRECTORY "${arg_INSTALL_DIRECTORY}"
"${plugin_type}"
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
"${install_directory_default}" install_directory)
set(archive_install_directory ${arg_ARCHIVE_INSTALL_DIRECTORY})
if (NOT archive_install_directory AND install_directory)
set(archive_install_directory "${install_directory}")
endif()
endif()
Fix potentially wrong version in Windows resources of Qt plugins qt_internal_add_plugin calls qt_set_target_info_properties with the TARGET_VERSION argument and passes arg_VERSION. However, the function qt_internal_add_plugin does not have a VERSION argument. If arg_VERSION is set before calling qt_internal_add_plugin, that value will be used, and that could be wrong for the plugin. Remove the TARGET_VERSION argument from the qt_set_target_info_properties call. Pick-to: 6.4 Change-Id: I0ae9e0e6636d74fdc20e6ab9ca525c5a9126000c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-06 09:00:15 +00:00
qt_set_target_info_properties(${target} ${ARGN})
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
CMake: Record used package version for each target dependency When recording which package version to look for in QtFooModuleDependencies.cmake and other files like it, instead of using PROJECT_VERSION, use the version of the package that contains the dependency. For example if we're hypothetically building the qtdeclarative repo from the 6.4 branch, against an installed 6.2 qtbase, then the Qt6QmlModuleDependencies.cmake file will have a find_package(Qt6Core 6.2) call because qtdeclarative's find_package(Qt6Core) call found a 6.2 Core when it was configured. This allows switching the versioning scheme of specific Qt modules that might not want to follow the general Qt versioning scheme. The first candidate would be QtWebEngine which might want to follow the Chromium versioning scheme, something like Qt 6.94.0 where 94 is the Chromium major version. Implementation notes. We now record the package version of a target in a property called _qt_package_version. We do it for qt modules, plugins, 3rd party libraries, tools and the Platform target. When we try to look up which version to write into the QtFooModuleDependencies.cmake file (or the equivalent Plugins and Tools file), we try to find the version from a few sources: the property mentioned above, then the Qt6{target}_VERSION variable, and finally PROJECT_VERSION. In the latter case, we issue a warning because technically that should never have to happen, and it's a bug or an unforeseen case if it does. A few more places also need adjustments: - package versions to look for when configuring standalone tests and generating standalone tests Config files - handling of tools packages - The main Qt6 package lookup in each Dependencies.cmake files Note that there are some requirements and consequences in case a module wants to use a different versioning scheme like 6.94.0. Requirements. - The root CMakeLists.txt file needs to call find_package with a version different from the usual PROJECT_VERSION. Ideally it should look for a few different Qt versions which are known to be compatible, for example the last stable and LTS versions, or just the lowest supported Qt version, e.g. 6.2.6 or whenever this change would land in the 6.2 branch. - If the repository has multiple modules, some of which need to follow the Qt versioning scheme and some not, project(VERSION x.y.z) calls need to be carefully placed in subdirectory scopes with appropriate version numbers, so that qt_internal_add_module / _tool / _plugin pick up the correct version. Consequences. - The .so / .dylib names will contain the new version, e.g. .so.6.94 - Linux ELF symbols will contain the new versions - syncqt private headers will now exist under a include/QtFoo/6.94.0/QtFoo/private folder - pri and prl files will also contain the new version numbers - pkg-config .pc files contain the new version numbers - It won't be possible to write find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code. One would have to write find_package(Qt6WebEngineWidgets 6.94) otherwise CMake will try to look for Qt6Config 6.94 which won't exist. - Similarly, a find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call would always find any kind of WebEngine package that is higher than 6.4, which might be 6.94, 6.95, etc. - In the future, if we fix Qt6Config to pass EXACT to its subcomponent find_package calls, a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets) would fail to find WebEngineWidgets, because its 6.94.0 version will not be equal to 6.5.0. Currently we don't pass through EXACT, so it's not an issue. Augments 5ffc744b791a114a3180a425dd26e298f7399955 Task-number: QTBUG-103500 Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-17 06:44:43 +00:00
set_target_properties(${target} PROPERTIES
_qt_package_version "${PROJECT_VERSION}"
)
set_property(TARGET ${target}
APPEND PROPERTY
EXPORT_PROPERTIES "_qt_package_version")
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
# Override the OUTPUT_NAME that qt6_add_plugin() set, we need to account for
# QT_LIBINFIX, which is specific to building Qt.
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
# Make sure the Qt6 plugin library names are like they were in Qt5 qmake land.
# Whereas the Qt6 CMake target names are like the Qt5 CMake target names.
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
get_target_property(output_name ${target} OUTPUT_NAME)
CMake Build: Add support for -qtlibinfix configure parameter Rename all libQt6*.so to libQt6*<infix>.so Task-number: QTBUG-85438 Change-Id: I4b91ffaaec7bea61454b0d3c794c77f2d0868d54 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-21 13:45:28 +00:00
set_property(TARGET "${target}" PROPERTY OUTPUT_NAME "${output_name}${QT_LIBINFIX}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
# Add a custom target with the Qt5 qmake name for a more user friendly ninja experience.
if(arg_OUTPUT_NAME AND NOT TARGET "${output_name}")
Fix build of QTuioTouchPlugin with Makefile generator on macOS For each plugin, we create a custom target with it's OUTPUT_NAME such that one simply can do 'ninja qtuiotouchplugin' to build it. QTuiTouchPlugin has qtuiotouchplugin as OUTPUT_NAME, which is problematic with Makefile generators on case-insensitive file systems. See CMake upstream issue #21915 for details. Work around this issue by not creating the custom target in this situation. Pick-to: 6.1 Fixes: QTBUG-84342 Change-Id: Id9a6cf0a01c179d5c93da4146e393cf00153ac4f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-11 10:19:48 +00:00
# But don't create such a target if it would just differ in case from "${target}"
# and we're not using Ninja. See https://gitlab.kitware.com/cmake/cmake/-/issues/21915
string(TOUPPER "${output_name}" uc_output_name)
string(TOUPPER "${target}" uc_target)
if(NOT uc_output_name STREQUAL uc_target OR CMAKE_GENERATOR MATCHES "^Ninja")
add_custom_target("${output_name}")
add_dependencies("${output_name}" "${target}")
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endif()
CMake: set correct COMPILE_PDB_NAME for static libraries Output names of static libraries might be different from target names. For example, the library name of Qt6::DeviceDiscoverySupportPrivate is "Qt6DeviceDiscoverySupport.lib", and the library name of Qt6::QTlsBackendCertOnlyPlugin is "qcertonlybackend.lib". This commit make pdb files names consistent with the library names. And make sure we have set correct OUTPUT_NAME property before calling qt_set_common_target_properties()/qt_internal_set_compile_pdb_names(). Change-Id: Idb3cacd7a46a4f298fd584b927b5d726956faea8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-04-30 15:38:02 +00:00
qt_set_common_target_properties("${target}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
qt_internal_add_target_aliases("${target}")
qt_skip_warnings_are_errors_when_repo_unclean("${target}")
_qt_internal_apply_strict_cpp("${target}")
set_target_properties("${target}" PROPERTIES
LIBRARY_OUTPUT_DIRECTORY "${output_directory}"
RUNTIME_OUTPUT_DIRECTORY "${output_directory}"
ARCHIVE_OUTPUT_DIRECTORY "${output_directory}"
QT_PLUGIN_TYPE "${plugin_type_escaped}"
# Save the non-sanitized plugin type values for qmake consumption via .pri files.
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-04 14:18:44 +00:00
QT_QMAKE_PLUGIN_TYPE "${plugin_type}"
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
)
qt_handle_multi_config_output_dirs("${target}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
qt_internal_library_deprecation_level(deprecation_define)
qt_autogen_tools_initial_setup(${target})
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
unset(plugin_install_package_suffix)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
CMake: Fix duplicate symbol errors in Windows static super builds qt_internal_add_executable has some special logic to link static plugins in order to avoid issues with link cycles on exported Qt module targets. This logic does not take into account if a plugin is a default plugin. On windows this caused duplicate symbol linking issues in static super builds, because both qwindows and qdirect2d define a subset of the same symbols. Make sure to only link to default static plugins. This will skip linking to qdirect2d because it's not a default qpa plugin and thus avoid linker issues. Amends 5807e1ae8168a5702ad0f6890d2b35223cfebdee Pick-to: 6.1 6.1.0 Fixes: QTBUG-92451 Change-Id: I56df2ce0201625088417de53038642518c1d3bbd Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-07 10:00:09 +00:00
# The generic plugins should be enabled by default.
# But platform plugins should always be disabled by default, and only one is enabled
# based on the platform (condition specified in arg_DEFAULT_IF).
if(plugin_type_escaped STREQUAL "platforms")
set(_default_plugin 0)
else()
set(_default_plugin 1)
endif()
CMake: Fix condition evaluation in plugin's DEFAULT_IF option Expand the condition without an extra negation. This fixes incorrect condition evaluation for conditions not enclosed in parenthesis. Pick-to: 6.1 Change-Id: I4923059b6b199676058091c23d51c9368daaebd0 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-08 11:32:26 +00:00
if(DEFINED arg_DEFAULT_IF)
if(${arg_DEFAULT_IF})
set(_default_plugin 1)
else()
set(_default_plugin 0)
endif()
CMake: Fix duplicate symbol errors in Windows static super builds qt_internal_add_executable has some special logic to link static plugins in order to avoid issues with link cycles on exported Qt module targets. This logic does not take into account if a plugin is a default plugin. On windows this caused duplicate symbol linking issues in static super builds, because both qwindows and qdirect2d define a subset of the same symbols. Make sure to only link to default static plugins. This will skip linking to qdirect2d because it's not a default qpa plugin and thus avoid linker issues. Amends 5807e1ae8168a5702ad0f6890d2b35223cfebdee Pick-to: 6.1 6.1.0 Fixes: QTBUG-92451 Change-Id: I56df2ce0201625088417de53038642518c1d3bbd Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-07 10:00:09 +00:00
endif()
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
# Save the Qt module in the plug-in's properties and vice versa
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
if(NOT plugin_type_escaped STREQUAL "qml_plugin")
Make qt_get_module_for_plugin() internal and do what its name says Contrary to its name, this command was also setting a target property. Since it was only called in one place and that caller can just as easily set the property instead, rename the command to make clear its internal nature and refactor it so that the caller is responsible for setting that property instead. Also make it an error rather than just a warning if the command is used for a target that doesn't belong to any module. Since this is now unambiguously an internal command, we should always expect the target to belong to a module. Pick-to: 6.1 Change-Id: I929a652ddd482653868fc9df887f38f4bc7f35d9 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-03-01 06:17:54 +00:00
qt_internal_get_module_for_plugin("${target}" "${plugin_type_escaped}" qt_module)
CMake: Semi-handle non-current repo qt modules when creating plugins In the recent refactoring of qt_internal_add_plugin, a new target existence check was added when associating a plugin with a qt module. That check didn't account for a qualified qt module target name. This failed configuration of qtsvg which checked for the existence of a namespace-less 'Gui' in a per-repo build. Make sure to prepend the Qt namespace to the qt module name and also handle aliased target names. As a drive-by, add a TODO item to figure out how to link executables to plugins who's plugin type belong to a different repo, but both the executable and plugin are built in the current repo. Amends aa4a1006cbccbc180c600f9b4dc9e882bb5ed5ca Fixes: QTBUG-92235 Change-Id: I1c0f83672ab00f4702be9bad9a66ccc35e82f5c8 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2021-03-30 07:27:04 +00:00
set(qt_module_target "${QT_CMAKE_EXPORT_NAMESPACE}::${qt_module}")
if(NOT TARGET "${qt_module_target}")
message(FATAL_ERROR "Failed to associate Qt plugin with Qt module. ${qt_module_target} is not a known CMake target")
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
endif()
CMake: Semi-handle non-current repo qt modules when creating plugins In the recent refactoring of qt_internal_add_plugin, a new target existence check was added when associating a plugin with a qt module. That check didn't account for a qualified qt module target name. This failed configuration of qtsvg which checked for the existence of a namespace-less 'Gui' in a per-repo build. Make sure to prepend the Qt namespace to the qt module name and also handle aliased target names. As a drive-by, add a TODO item to figure out how to link executables to plugins who's plugin type belong to a different repo, but both the executable and plugin are built in the current repo. Amends aa4a1006cbccbc180c600f9b4dc9e882bb5ed5ca Fixes: QTBUG-92235 Change-Id: I1c0f83672ab00f4702be9bad9a66ccc35e82f5c8 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2021-03-30 07:27:04 +00:00
Make qt_get_module_for_plugin() internal and do what its name says Contrary to its name, this command was also setting a target property. Since it was only called in one place and that caller can just as easily set the property instead, rename the command to make clear its internal nature and refactor it so that the caller is responsible for setting that property instead. Also make it an error rather than just a warning if the command is used for a target that doesn't belong to any module. Since this is now unambiguously an internal command, we should always expect the target to belong to a module. Pick-to: 6.1 Change-Id: I929a652ddd482653868fc9df887f38f4bc7f35d9 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-03-01 06:17:54 +00:00
set_target_properties("${target}" PROPERTIES QT_MODULE "${qt_module}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
set(plugin_install_package_suffix "${qt_module}")
CMake: Semi-handle non-current repo qt modules when creating plugins In the recent refactoring of qt_internal_add_plugin, a new target existence check was added when associating a plugin with a qt module. That check didn't account for a qualified qt module target name. This failed configuration of qtsvg which checked for the existence of a namespace-less 'Gui' in a per-repo build. Make sure to prepend the Qt namespace to the qt module name and also handle aliased target names. As a drive-by, add a TODO item to figure out how to link executables to plugins who's plugin type belong to a different repo, but both the executable and plugin are built in the current repo. Amends aa4a1006cbccbc180c600f9b4dc9e882bb5ed5ca Fixes: QTBUG-92235 Change-Id: I1c0f83672ab00f4702be9bad9a66ccc35e82f5c8 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2021-03-30 07:27:04 +00:00
get_target_property(aliased_target ${qt_module_target} ALIASED_TARGET)
if(aliased_target)
set(qt_module_target ${aliased_target})
endif()
get_target_property(is_imported_qt_module ${qt_module_target} IMPORTED)
CMake: Add shared library plugin names to the QT_PLUGINS property Otherwise we don't create a Qt6FooPlugins.cmake file in shared Qt builds. Adjust comment. Amends f68e2c92cc0ed2c1929140402c061359bc2363a5 Related to 7d6f1ee5a75cae9d122a3f0c7b3a6d03f380535e Change-Id: I9c66d81197a4867039d5c53daf1b7edf0391c701 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2022-07-27 09:35:50 +00:00
if(NOT is_imported_qt_module)
# This QT_PLUGINS assignment is only used by QtPostProcessHelpers to decide if a
# QtModulePlugins.cmake file should be generated.
set_property(TARGET "${qt_module_target}" APPEND PROPERTY QT_PLUGINS "${target}")
endif()
cmake: Link static plugins even in shared Qt builds It's perfectly possible to create static plugins in an otherwise shared Qt build, but the logic to import these plugins into applications was assuming a fully static Qt build. We now handle this more granularly. This works for in-source tools and tests as well, which don't go through the same CMake machinery for plugins as user projects do. The only case that does not currently work is in-source examples, as they don't share any of the plugin machinery with neither Qt internal tools/tests or user project, but that's a bigger architectural issue that goes beyond this change. Change-Id: Ie00a97b02ac38ec4affadc447a3bfd0ec7d9c69a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-18 12:20:37 +00:00
set(plugin_target_versioned "${QT_CMAKE_EXPORT_NAMESPACE}::${target}")
get_target_property(type "${plugin_target_versioned}" TYPE)
if(type STREQUAL STATIC_LIBRARY)
# Associate plugin with its Qt module when both are both built in the same repository.
# Check that by comparing the PROJECT_NAME of each.
# This covers auto-linking of the majority of plugins to executables and in-tree tests.
# Linking of plugins in standalone tests (when the Qt module will be an imported target)
# is handled instead by the complicated genex logic in QtModulePlugins.cmake.in.
set(is_plugin_and_module_in_same_project FALSE)
if(NOT is_imported_qt_module)
get_target_property(module_source_dir ${qt_module_target} SOURCE_DIR)
get_directory_property(module_project_name
DIRECTORY ${module_source_dir}
DEFINITION PROJECT_NAME
)
if(module_project_name STREQUAL PROJECT_NAME)
set(is_plugin_and_module_in_same_project TRUE)
endif()
# When linking static plugins with the special logic in qt_internal_add_executable,
# make sure to skip non-default plugins.
if(is_plugin_and_module_in_same_project AND _default_plugin)
set_property(TARGET ${qt_module_target} APPEND PROPERTY
_qt_initial_repo_plugins
"${target}")
set_property(TARGET ${qt_module_target} APPEND PROPERTY
_qt_initial_repo_plugin_class_names
"$<TARGET_PROPERTY:${target},QT_PLUGIN_CLASS_NAME>"
)
endif()
CMake: Fix auto-linking of static plugins for non-QML in-tree tests Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-20 15:29:48 +00:00
endif()
CMake: Fix duplicate symbol errors in Windows static super builds qt_internal_add_executable has some special logic to link static plugins in order to avoid issues with link cycles on exported Qt module targets. This logic does not take into account if a plugin is a default plugin. On windows this caused duplicate symbol linking issues in static super builds, because both qwindows and qdirect2d define a subset of the same symbols. Make sure to only link to default static plugins. This will skip linking to qdirect2d because it's not a default qpa plugin and thus avoid linker issues. Amends 5807e1ae8168a5702ad0f6890d2b35223cfebdee Pick-to: 6.1 6.1.0 Fixes: QTBUG-92451 Change-Id: I56df2ce0201625088417de53038642518c1d3bbd Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-07 10:00:09 +00:00
cmake: Link static plugins even in shared Qt builds It's perfectly possible to create static plugins in an otherwise shared Qt build, but the logic to import these plugins into applications was assuming a fully static Qt build. We now handle this more granularly. This works for in-source tools and tests as well, which don't go through the same CMake machinery for plugins as user projects do. The only case that does not currently work is in-source examples, as they don't share any of the plugin machinery with neither Qt internal tools/tests or user project, but that's a bigger architectural issue that goes beyond this change. Change-Id: Ie00a97b02ac38ec4affadc447a3bfd0ec7d9c69a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-18 12:20:37 +00:00
# Associate plugin with its Qt module when the plugin is built in the current repository
# but the module is built in a different repository (qtsvg's QSvgPlugin associated with
# qtbase's QtGui).
# The association is done in a separate property, to ensure that reconfiguring in-tree tests
# in qtbase doesn't accidentally cause linking to a plugin from a previously built qtsvg.
# Needed for in-tree tests like in qtsvg, qtimageformats.
# This is done for each Qt module regardless if it's an imported target or not, to handle
# both per-repo and top-level builds (in per-repo build of qtsvg QtGui is imported, in a
# top-level build Gui is not imported, but in both cases qtsvg tests need to link to
# QSvgPlugin).
#
# TODO: Top-level in-tree tests and qdeclarative per-repo in-tree tests that depend on
# static Qml plugins won't work due to the requirement of running qmlimportscanner
# at configure time, but qmlimportscanner is not built at that point. Moving the
# execution of qmlimportscanner to build time is non-trivial because qmlimportscanner
# not only generates a cpp file to compile but also outputs a list of static plugins
# that should be linked and there is no straightforward way to tell CMake to link
# against a list of libraries that was discovered at build time (apart from
# response files, which apparently might not work on all platforms).
# qmake doesn't have this problem because each project is configured separately so
# qmlimportscanner is always built by the time it needs to be run for a test.
if(NOT is_plugin_and_module_in_same_project AND _default_plugin)
string(MAKE_C_IDENTIFIER "${PROJECT_NAME}" current_project_name)
set(prop_prefix "_qt_repo_${current_project_name}")
CMake: Fix auto-linking of static plugins for non-QML in-tree tests Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-20 15:29:48 +00:00
set_property(TARGET ${qt_module_target} APPEND PROPERTY
cmake: Link static plugins even in shared Qt builds It's perfectly possible to create static plugins in an otherwise shared Qt build, but the logic to import these plugins into applications was assuming a fully static Qt build. We now handle this more granularly. This works for in-source tools and tests as well, which don't go through the same CMake machinery for plugins as user projects do. The only case that does not currently work is in-source examples, as they don't share any of the plugin machinery with neither Qt internal tools/tests or user project, but that's a bigger architectural issue that goes beyond this change. Change-Id: Ie00a97b02ac38ec4affadc447a3bfd0ec7d9c69a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-18 12:20:37 +00:00
${prop_prefix}_plugins "${target}")
CMake: Fix auto-linking of static plugins for non-QML in-tree tests Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-20 15:29:48 +00:00
set_property(TARGET ${qt_module_target} APPEND PROPERTY
cmake: Link static plugins even in shared Qt builds It's perfectly possible to create static plugins in an otherwise shared Qt build, but the logic to import these plugins into applications was assuming a fully static Qt build. We now handle this more granularly. This works for in-source tools and tests as well, which don't go through the same CMake machinery for plugins as user projects do. The only case that does not currently work is in-source examples, as they don't share any of the plugin machinery with neither Qt internal tools/tests or user project, but that's a bigger architectural issue that goes beyond this change. Change-Id: Ie00a97b02ac38ec4affadc447a3bfd0ec7d9c69a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-18 12:20:37 +00:00
${prop_prefix}_plugin_class_names
"$<TARGET_PROPERTY:${target},QT_PLUGIN_CLASS_NAME>"
CMake: Fix auto-linking of static plugins for non-QML in-tree tests Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-20 15:29:48 +00:00
)
CMake: Semi-handle non-current repo qt modules when creating plugins In the recent refactoring of qt_internal_add_plugin, a new target existence check was added when associating a plugin with a qt module. That check didn't account for a qualified qt module target name. This failed configuration of qtsvg which checked for the existence of a namespace-less 'Gui' in a per-repo build. Make sure to prepend the Qt namespace to the qt module name and also handle aliased target names. As a drive-by, add a TODO item to figure out how to link executables to plugins who's plugin type belong to a different repo, but both the executable and plugin are built in the current repo. Amends aa4a1006cbccbc180c600f9b4dc9e882bb5ed5ca Fixes: QTBUG-92235 Change-Id: I1c0f83672ab00f4702be9bad9a66ccc35e82f5c8 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2021-03-30 07:27:04 +00:00
endif()
CMake: Fix auto-linking of static plugins for non-QML in-tree tests Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-20 15:29:48 +00:00
endif()
Replace the syncqt.pl script with syncqt tool syncqt.pl adds an extra dependency on perl when building Qt. Modern C++ provides the convenient cross-platform way to access a filesystem and to use regular expressions, so we may replace the perl script with C++ application. The syncqt executable is built at configure time and installed as QtCore tool. It's running at configure time to deliver the required header files for IDE to build a consistent code model and at the build time to keep tracking changes in header files and generate the missing aliases without reconfiguring. 'syncqt' only parses header files from a CMake build tree, so the resulting Qt installation only contains interfacing headers that belong to the platform that Qt is built for. 'sync.profile' files are not used as the 'source of truth' for sync qt procedure anymore, all the necessary information is taken from either CMake files at configure time or from the module header files while parsing them. syncqt.pl is still in place since it's required as fallback solution for a smooth transition to the new syncqt implementation for all qt repositories. This patchset only enables the C++ based syncqt for 'qtbase' repository. From the performance perspective C++ version works faster then perl script, also the configure time is reduced significally on subsequent reconfigurations - up x2 times faster when re-configuring repository, but it also takes time to compile the tool itself the first time. Numbers for qtbase: syncqt.pl syncqt.cpp initial: 0m16,035s 0m20,413s reconfig: 0m6,819s 0m3,725s The syncing procedure can be run separately for each module using <ModuleName>_sync_headers targets. The 'sync_headers' target can be used to sync all the modules at once. Task-number: QTBUG-87480 Task-number: QTBUG-103196 Change-Id: I8c938bcaf88a8713b39bbfd66d9e7ef12b2c3523 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-15 16:29:41 +00:00
qt_internal_add_autogen_sync_header_dependencies(${target} ${qt_module_target})
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endif()
# Change the configuration file install location for qml plugins into the Qml package location.
if(plugin_type_escaped STREQUAL "qml_plugin" AND TARGET "${INSTALL_CMAKE_NAMESPACE}::Qml")
set(plugin_install_package_suffix "Qml/QmlPlugins")
endif()
# Save the install package suffix as a property, so that the Dependencies file is placed
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
# in the correct location.
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
if(plugin_install_package_suffix)
set_target_properties("${target}" PROPERTIES
_qt_plugin_install_package_suffix "${plugin_install_package_suffix}")
endif()
Skip adding externally added plugins to the plugin meta-sets Plugin meta-sets are not visible outside of the module build tree, so there is no point in adding dependencies for externally added plugins. Change-Id: Ica5b29b57c032f4fc9b128172aaa806392e9e581 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-08 13:55:09 +00:00
if(TARGET qt_plugins)
add_dependencies(qt_plugins "${target}")
endif()
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-04 14:18:44 +00:00
if(plugin_type STREQUAL "platforms")
Skip adding externally added plugins to the plugin meta-sets Plugin meta-sets are not visible outside of the module build tree, so there is no point in adding dependencies for externally added plugins. Change-Id: Ica5b29b57c032f4fc9b128172aaa806392e9e581 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-08 13:55:09 +00:00
if(TARGET qpa_plugins)
add_dependencies(qpa_plugins "${target}")
endif()
CMake: Fix target dependency cycle regarding qpa plugins in qtwayland With the introduction of the new 'default_qpa_plugins' custom target, a target dependency cycle occurred in qtwayland: qtwaylandscanner -> default_qpa_plugins -> a wayland qpa plugin -> WaylandClient -> qtwaylandscanner The issue is twofold: - default_qpa_plugins accidentally depended on non-qpa plugins. - All qpa plugins were enabled by default, including the wayland ones. Fix the default_qpa_plugins target not to depend on regular non-qpa plugins. Also fix qpa plugins not to be enabled by default, but instead only choose one qpa plugin to be the default (via evaluating the DEFAULT_IF) condition. Amends df9c7456d11dfcf74c7399ba0981a3ba3d3f5117 Change-Id: I22cd2c72f6b75be54263fd21097258bd179e3616 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-26 10:24:27 +00:00
Skip adding externally added plugins to the plugin meta-sets Plugin meta-sets are not visible outside of the module build tree, so there is no point in adding dependencies for externally added plugins. Change-Id: Ica5b29b57c032f4fc9b128172aaa806392e9e581 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-08 13:55:09 +00:00
if(_default_plugin AND TARGET qpa_default_plugins)
CMake: Fix target dependency cycle regarding qpa plugins in qtwayland With the introduction of the new 'default_qpa_plugins' custom target, a target dependency cycle occurred in qtwayland: qtwaylandscanner -> default_qpa_plugins -> a wayland qpa plugin -> WaylandClient -> qtwaylandscanner The issue is twofold: - default_qpa_plugins accidentally depended on non-qpa plugins. - All qpa plugins were enabled by default, including the wayland ones. Fix the default_qpa_plugins target not to depend on regular non-qpa plugins. Also fix qpa plugins not to be enabled by default, but instead only choose one qpa plugin to be the default (via evaluating the DEFAULT_IF) condition. Amends df9c7456d11dfcf74c7399ba0981a3ba3d3f5117 Change-Id: I22cd2c72f6b75be54263fd21097258bd179e3616 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-26 10:24:27 +00:00
add_dependencies(qpa_default_plugins "${target}")
endif()
CMake: Add convenience custom targets to build Qt plugins Add 3 new convenience custom targets: 'qt_plugins', 'qpa_plugins' and 'qpa_default_plugins'. Additionally, if we detect that an internal executable / test links against Gui, add a dependency on the 'qpa_default_plugins' custom target, so that if a developer configures Qt for the first time and then calls ninja 'tst_foo_check', we ensure the test will launch successfully because the default QPA plugin will also be built. Change-Id: If6dd70844b5effdf8a293f65f8785855cc85b132 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-19 17:34:53 +00:00
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
set_property(TARGET "${target}" PROPERTY QT_DEFAULT_PLUGIN "${_default_plugin}")
set_property(TARGET "${target}" APPEND PROPERTY EXPORT_PROPERTIES "QT_PLUGIN_CLASS_NAME;QT_PLUGIN_TYPE;QT_MODULE;QT_DEFAULT_PLUGIN")
set(private_includes
"${CMAKE_CURRENT_SOURCE_DIR}"
"${CMAKE_CURRENT_BINARY_DIR}"
# For the syncqt headers
Remove use of qt_internal_module_info from qt_internal_add_plugin Plugin targets don't fit the requirements of the module but use the function associated to the module. The purpose of using qt_internal_module_info is to get the path to the top-level include directory. So there is no point in breaking the encapsulation rules to get a well-known directory. Change-Id: If3d2a31d4ec186929e3d662a79a1ae9eac988d1a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 14:01:51 +00:00
"$<BUILD_INTERFACE:${QT_BUILD_DIR}/include>"
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
${arg_INCLUDE_DIRECTORIES}
)
set(public_includes
${arg_PUBLIC_INCLUDE_DIRECTORIES}
)
CMake: Rename internal functions to contain qt_internal Offer compatibility wrapper functions until we update all of the Qt repos to use the new names. Task-number: QTBUG-86815 Change-Id: I5826a4116f52a8509db32601ef7c200f9bd331de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2020-09-22 08:02:27 +00:00
qt_internal_extend_target("${target}"
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
SOURCES ${arg_SOURCES}
INCLUDE_DIRECTORIES
${private_includes}
CMake: add SYSTEM_INCLUDE_DIRECTORIES to qt_internal_extend_target This allows one to add an extra set of directories to the build, but let the compiler know that they are system paths (that is, the compiler should refrain from emitting warnings in code found there). This extends INCLUDE_DIRECTORIES and is by necessity a private include set. Will be used by qtquick3dphysics, due to its PhysX dependency. Change-Id: I76216ced393445a4ae2dfffd1729c556db0cce3d Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-11-22 01:55:13 +00:00
SYSTEM_INCLUDE_DIRECTORIES
${arg_SYSTEM_INCLUDE_DIRECTORIES}
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
PUBLIC_INCLUDE_DIRECTORIES
${public_includes}
LIBRARIES ${arg_LIBRARIES} Qt::PlatformPluginInternal
PUBLIC_LIBRARIES ${arg_PUBLIC_LIBRARIES}
DEFINES
${arg_DEFINES}
CMake: Fix deprecation defines not being set properly Instead of propagating the deprecation wranings, we compiled all code with -Ddeprecations. Change-Id: I0233ddc85bdbdcb93d366073b2cea5d47bdbe52a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-19 17:34:17 +00:00
${deprecation_define}
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
PUBLIC_DEFINES
${arg_PUBLIC_DEFINES}
FEATURE_DEPENDENCIES ${arg_FEATURE_DEPENDENCIES}
DBUS_ADAPTOR_SOURCES "${arg_DBUS_ADAPTOR_SOURCES}"
DBUS_ADAPTOR_FLAGS "${arg_DBUS_ADAPTOR_FLAGS}"
DBUS_INTERFACE_SOURCES "${arg_DBUS_INTERFACE_SOURCES}"
DBUS_INTERFACE_FLAGS "${arg_DBUS_INTERFACE_FLAGS}"
COMPILE_OPTIONS ${arg_COMPILE_OPTIONS}
PUBLIC_COMPILE_OPTIONS ${arg_PUBLIC_COMPILE_OPTIONS}
LINK_OPTIONS ${arg_LINK_OPTIONS}
PUBLIC_LINK_OPTIONS ${arg_PUBLIC_LINK_OPTIONS}
MOC_OPTIONS ${arg_MOC_OPTIONS}
ENABLE_AUTOGEN_TOOLS ${arg_ENABLE_AUTOGEN_TOOLS}
DISABLE_AUTOGEN_TOOLS ${arg_DISABLE_AUTOGEN_TOOLS}
)
Clear non-relevant CMake compiler flags Add internal function to cleanup compiler flags out of the CMAKE_xxx_FLAGS_xxx variables. Use introduced interface to clear the '/EHsc' flag for the MSVC compiler family. This adjusts the CMake behavior to the qmake one. Change the 'EXCEPTIONS' option handling in helper functions. Add ability to add enabling and disabling exception flags. Previously it was only possible to add disabling exception flags. Fixes: QTBUG-89952 Change-Id: I60d47660a97ae9b5a1d1f4107d352c9e97890144 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-01-21 10:17:58 +00:00
build system: support module local definitions This introduces a new helper function, qt_internal_add_repo_local_defines and makes use of it in qt_internal_add_{module,test,executable,benchmark,plugin}. That function checks whether QT_EXTRA_INTERNAL_TARGET_DEFINES is set. If it is, the defines listed in there will be aded to all targets passed to the functions mentioned above. The intended usage is that QT_EXTRA_INTERNAL_TARGET_DEFINES gets set in the repository local .cmake.conf. This allows e.g. opting in to source incompatible changes in leaf modules (as long as those are guarded by some define). Pick-to: 6.2 6.3 Fixes: QTBUG-101640 Change-Id: I06c3693ee69f46e95a48de724621f0c97e7cc3a8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-03-11 11:41:36 +00:00
qt_internal_add_repo_local_defines("${target}")
Clear non-relevant CMake compiler flags Add internal function to cleanup compiler flags out of the CMAKE_xxx_FLAGS_xxx variables. Use introduced interface to clear the '/EHsc' flag for the MSVC compiler family. This adjusts the CMake behavior to the qmake one. Change the 'EXCEPTIONS' option handling in helper functions. Add ability to add enabling and disabling exception flags. Previously it was only possible to add disabling exception flags. Fixes: QTBUG-89952 Change-Id: I60d47660a97ae9b5a1d1f4107d352c9e97890144 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-01-21 10:17:58 +00:00
qt_internal_set_exceptions_flags("${target}" ${arg_EXCEPTIONS})
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
set(qt_libs_private "")
qt_internal_get_qt_all_known_modules(known_modules)
foreach(it ${known_modules})
list(FIND arg_LIBRARIES "Qt::${it}Private" pos)
if(pos GREATER -1)
list(APPEND qt_libs_private "Qt::${it}Private")
endif()
endforeach()
qt_register_target_dependencies("${target}" "${arg_PUBLIC_LIBRARIES}" "${qt_libs_private}")
CMake: Don't generate .pri files for qml plugins We didn't do it in Qt 5 times and it was accidentally done for Qt 6. There's no reason to generate them, the .pri files are only meant to be used for regular plugins so a project can do QTPLUGINS += foo. That mechanism is not needed for qml plugins which use qmlimportscanner instead. Furthermore the pri contents didn't contain a class name, so they couldn't be used anyway. Pick-to: 6.2 Change-Id: I6299fda21ece0f693a817ab558b45aa46b97e5ee Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-11 14:56:59 +00:00
cmake: Generate prl and pri files for static plugins in shared Qt builds The CMake build system files are properly generated, but the qmake parts were missing. Change-Id: Icbcce3143db976c536c802ea2314bc3f2595da51 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-18 12:31:37 +00:00
get_target_property(target_type "${target}" TYPE)
if(target_type STREQUAL STATIC_LIBRARY)
CMake: Build plugin initializers as object libs Instead of compiling the plugin initializers as part of a user project, pre-compile them as object libraries while building Qt. The installed object libraries can then be used with target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) so that they are linked into the final executable or shared library via qt module usage requirement propagation. This reduces the build times of user projects. The link line placement of the object files should be correct for all linux-y linkers because the only dependency for the object files is Core and the Gui -> plugin -> Gui -> Core cycle does not hamper that from empirical observations. As a consequence of the recent change not to link plugin initialization object files into static libraries, as well not having to compile the files in user projects, we can get rid of the _qt_internal_disable_static_default_plugins calls in various places. A side note. Consider a user static library (L) that links to a Qt static library (Gui) which provides plugins (platform plugins). If there is an executable (E) that links to (L), with no direct dependency to any other Qt module and the intention is that the executable will automatically get the platform plugin linked, then (L) needs to link PUBLIC-ly to (Gui) so that the plugin usage requirements are propagated successfully. This is a limitation of using target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which will propagate object files across static libraries only if qt_module is linked publicly. One could try to use target_link_libraries(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which preserves the linker arguments across static libs even if qt_module is linked privately, but unfortunately CMake will lose dependency information on Core, which means the object files might be placed in the wrong place on the link line. As far as I know this is a limitation of CMake that can't be worked around at the moment. Note this behavior was present before this change as well. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ia99e8aa3d32d6197cacd6162515ac808f2c6c53f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-11 09:19:19 +00:00
if(qt_module_target)
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-15 11:41:15 +00:00
qt_internal_link_internal_platform_for_object_library("${plugin_init_target}")
CMake: Build plugin initializers as object libs Instead of compiling the plugin initializers as part of a user project, pre-compile them as object libraries while building Qt. The installed object libraries can then be used with target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) so that they are linked into the final executable or shared library via qt module usage requirement propagation. This reduces the build times of user projects. The link line placement of the object files should be correct for all linux-y linkers because the only dependency for the object files is Core and the Gui -> plugin -> Gui -> Core cycle does not hamper that from empirical observations. As a consequence of the recent change not to link plugin initialization object files into static libraries, as well not having to compile the files in user projects, we can get rid of the _qt_internal_disable_static_default_plugins calls in various places. A side note. Consider a user static library (L) that links to a Qt static library (Gui) which provides plugins (platform plugins). If there is an executable (E) that links to (L), with no direct dependency to any other Qt module and the intention is that the executable will automatically get the platform plugin linked, then (L) needs to link PUBLIC-ly to (Gui) so that the plugin usage requirements are propagated successfully. This is a limitation of using target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which will propagate object files across static libraries only if qt_module is linked publicly. One could try to use target_link_libraries(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which preserves the linker arguments across static libs even if qt_module is linked privately, but unfortunately CMake will lose dependency information on Core, which means the object files might be placed in the wrong place on the link line. As far as I know this is a limitation of CMake that can't be worked around at the moment. Note this behavior was present before this change as well. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ia99e8aa3d32d6197cacd6162515ac808f2c6c53f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-11 09:19:19 +00:00
endif()
CMake: Generate less pri files and mark header modules as no_link Plugins will no longer get .pri files generated in non-static builds. Header modules are now marked in the .pri files as CONFIG += no_link. Pick-to: 6.0 6.0.0 Fixes: QTBUG-88221 Change-Id: I06e31fa970ad021261c43ca3acd88055cc4c9555 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-19 14:35:28 +00:00
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
if (NOT arg_SKIP_INSTALL)
# Handle creation of cmake files for consumers of find_package().
# If we are part of a Qt module, the plugin cmake files are installed as part of that
# module.
# For qml plugins, they are all installed into the QtQml package location for automatic
# discovery.
if(plugin_install_package_suffix)
set(path_suffix "${INSTALL_CMAKE_NAMESPACE}${plugin_install_package_suffix}")
else()
set(path_suffix "${INSTALL_CMAKE_NAMESPACE}${target}")
endif()
qt_path_join(config_build_dir ${QT_CONFIG_BUILD_DIR} ${path_suffix})
qt_path_join(config_install_dir ${QT_CONFIG_INSTALL_DIR} ${path_suffix})
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
qt_internal_export_additional_targets_file(
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
TARGETS ${target} ${plugin_init_target}
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
EXPORT_NAME_PREFIX ${INSTALL_CMAKE_NAMESPACE}${target}
CONFIG_INSTALL_DIR "${config_install_dir}")
CMake: Enable NEW policies by CMake version with a global default When a CMake release introduces a new policy that affects most Qt modules, it may be appropriate to make each module aware of that newer CMake version and use the NEW policy without raising the minimum CMake version requirement. To reduce the churn associated with making that change across all Qt modules individually, this change allows it to be updated in a central place (qtbase), but in a way that allows a Qt module to override it in its own .cmake.conf file if required (e.g. to address the issues identified by policy warnings at a later time). The policies are modified at the start of the call to qt_build_repo_begin(). For commands defined by the qtbase module, qtbase needs to be in control of the policy settings at the point where those commands are defined. The above mechanism should not affect the policy settings for these commands, so the various *Config.cmake.in files must not specify policy ranges in a way that a Qt module's .cmake.conf file could influence. Starting with CMake 3.12, policies can be specified as a version range with the cmake_minimum_required() and cmake_policy() commands. All policies introduced in CMake versions up to the upper limit of that range will be set to NEW. The actual version of CMake being used only has to be at least the lower limit of the specified version range. This change uses cmake_minimum_required() rather than cmake_policy() due to the latter not halting further processing upon failure. See the following: https://gitlab.kitware.com/cmake/cmake/-/issues/21557 Task-number: QTBUG-88700 Pick-to: 6.0 Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-30 07:46:49 +00:00
qt_internal_get_min_new_policy_cmake_version(min_new_policy_version)
qt_internal_get_max_new_policy_cmake_version(max_new_policy_version)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
configure_package_config_file(
"${QT_CMAKE_DIR}/QtPluginConfig.cmake.in"
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}Config.cmake"
INSTALL_DESTINATION "${config_install_dir}"
)
write_basic_package_version_file(
CMake: Allow disabling package version check When building Qt repos, all find_package(Qt6) calls request a PROJECT_VERSION version which is set in .cmake.conf via QT_REPO_MODULE_VERSION. This means trying to configure qtsvg from a 6.3 branch using a 6.2 qtbase won't work, because qtsvg will call find_package(Qt6 6.3) and no such Qt6 package version exists. There are certain scenarios where it might be useful to try to do that though. One of them is doing Qt development while locally mixing branches. Another is building a 6.4 QtWebEngine against a 6.2 Qt. Allow to opt out of the version check by configuring each Qt repo with -DQT_NO_PACKAGE_VERSION_CHECK=TRUE. This setting is not recorded and will have to be set again when configuring another repo. The version check will also be disabled by default when configuring with the -developer-build feature. This will be recorded and embedded into each ConfigVersion file. If the version check is disabled, a warning will be shown mentioning the incompatible version of a package that was found but that package will still be accepted. The warning will show both when building Qt or using Qt in a user project. The warnings can be disabled by passing -DQT_NO_PACKAGE_VERSION_INCOMPATIBLE_WARNING=TRUE Furthermore when building a Qt repo, another warning will show when an incompatible package version is detected, to suggest to the Qt builder whether they want to use the incompatible version by disabling the version check. Note that there are no compatibility promises when using mixed non-matching versions. Things might not work. These options are only provided for convenience and their users know what they are doing. Pick-to: 6.2 Fixes: QTBUG-96458 Change-Id: I1a42e0b2a00b73513d776d89a76102ffd9136422 Reviewed-by: Craig Scott <craig.scott@qt.io>
2021-10-22 11:38:00 +00:00
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}ConfigVersionImpl.cmake"
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
VERSION ${PROJECT_VERSION}
COMPATIBILITY AnyNewerVersion
)
CMake: Allow disabling package version check When building Qt repos, all find_package(Qt6) calls request a PROJECT_VERSION version which is set in .cmake.conf via QT_REPO_MODULE_VERSION. This means trying to configure qtsvg from a 6.3 branch using a 6.2 qtbase won't work, because qtsvg will call find_package(Qt6 6.3) and no such Qt6 package version exists. There are certain scenarios where it might be useful to try to do that though. One of them is doing Qt development while locally mixing branches. Another is building a 6.4 QtWebEngine against a 6.2 Qt. Allow to opt out of the version check by configuring each Qt repo with -DQT_NO_PACKAGE_VERSION_CHECK=TRUE. This setting is not recorded and will have to be set again when configuring another repo. The version check will also be disabled by default when configuring with the -developer-build feature. This will be recorded and embedded into each ConfigVersion file. If the version check is disabled, a warning will be shown mentioning the incompatible version of a package that was found but that package will still be accepted. The warning will show both when building Qt or using Qt in a user project. The warnings can be disabled by passing -DQT_NO_PACKAGE_VERSION_INCOMPATIBLE_WARNING=TRUE Furthermore when building a Qt repo, another warning will show when an incompatible package version is detected, to suggest to the Qt builder whether they want to use the incompatible version by disabling the version check. Note that there are no compatibility promises when using mixed non-matching versions. Things might not work. These options are only provided for convenience and their users know what they are doing. Pick-to: 6.2 Fixes: QTBUG-96458 Change-Id: I1a42e0b2a00b73513d776d89a76102ffd9136422 Reviewed-by: Craig Scott <craig.scott@qt.io>
2021-10-22 11:38:00 +00:00
qt_internal_write_qt_package_version_file(
"${INSTALL_CMAKE_NAMESPACE}${target}"
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}ConfigVersion.cmake"
)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
qt_install(FILES
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}Config.cmake"
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}ConfigVersion.cmake"
CMake: Allow disabling package version check When building Qt repos, all find_package(Qt6) calls request a PROJECT_VERSION version which is set in .cmake.conf via QT_REPO_MODULE_VERSION. This means trying to configure qtsvg from a 6.3 branch using a 6.2 qtbase won't work, because qtsvg will call find_package(Qt6 6.3) and no such Qt6 package version exists. There are certain scenarios where it might be useful to try to do that though. One of them is doing Qt development while locally mixing branches. Another is building a 6.4 QtWebEngine against a 6.2 Qt. Allow to opt out of the version check by configuring each Qt repo with -DQT_NO_PACKAGE_VERSION_CHECK=TRUE. This setting is not recorded and will have to be set again when configuring another repo. The version check will also be disabled by default when configuring with the -developer-build feature. This will be recorded and embedded into each ConfigVersion file. If the version check is disabled, a warning will be shown mentioning the incompatible version of a package that was found but that package will still be accepted. The warning will show both when building Qt or using Qt in a user project. The warnings can be disabled by passing -DQT_NO_PACKAGE_VERSION_INCOMPATIBLE_WARNING=TRUE Furthermore when building a Qt repo, another warning will show when an incompatible package version is detected, to suggest to the Qt builder whether they want to use the incompatible version by disabling the version check. Note that there are no compatibility promises when using mixed non-matching versions. Things might not work. These options are only provided for convenience and their users know what they are doing. Pick-to: 6.2 Fixes: QTBUG-96458 Change-Id: I1a42e0b2a00b73513d776d89a76102ffd9136422 Reviewed-by: Craig Scott <craig.scott@qt.io>
2021-10-22 11:38:00 +00:00
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}ConfigVersionImpl.cmake"
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
DESTINATION "${config_install_dir}"
COMPONENT Devel
)
# Make the export name of plugins be consistent with modules, so that
# qt_add_resource adds its additional targets to the same export set in a static Qt build.
set(export_name "${INSTALL_CMAKE_NAMESPACE}${target}Targets")
CMake: Build plugin initializers as object libs Instead of compiling the plugin initializers as part of a user project, pre-compile them as object libraries while building Qt. The installed object libraries can then be used with target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) so that they are linked into the final executable or shared library via qt module usage requirement propagation. This reduces the build times of user projects. The link line placement of the object files should be correct for all linux-y linkers because the only dependency for the object files is Core and the Gui -> plugin -> Gui -> Core cycle does not hamper that from empirical observations. As a consequence of the recent change not to link plugin initialization object files into static libraries, as well not having to compile the files in user projects, we can get rid of the _qt_internal_disable_static_default_plugins calls in various places. A side note. Consider a user static library (L) that links to a Qt static library (Gui) which provides plugins (platform plugins). If there is an executable (E) that links to (L), with no direct dependency to any other Qt module and the intention is that the executable will automatically get the platform plugin linked, then (L) needs to link PUBLIC-ly to (Gui) so that the plugin usage requirements are propagated successfully. This is a limitation of using target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which will propagate object files across static libraries only if qt_module is linked publicly. One could try to use target_link_libraries(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which preserves the linker arguments across static libs even if qt_module is linked privately, but unfortunately CMake will lose dependency information on Core, which means the object files might be placed in the wrong place on the link line. As far as I know this is a limitation of CMake that can't be worked around at the moment. Note this behavior was present before this change as well. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ia99e8aa3d32d6197cacd6162515ac808f2c6c53f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-11 09:19:19 +00:00
qt_install(TARGETS
"${target}"
${plugin_init_target}
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
EXPORT ${export_name}
RUNTIME DESTINATION "${install_directory}"
LIBRARY DESTINATION "${install_directory}"
CMake: Build plugin initializers as object libs Instead of compiling the plugin initializers as part of a user project, pre-compile them as object libraries while building Qt. The installed object libraries can then be used with target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) so that they are linked into the final executable or shared library via qt module usage requirement propagation. This reduces the build times of user projects. The link line placement of the object files should be correct for all linux-y linkers because the only dependency for the object files is Core and the Gui -> plugin -> Gui -> Core cycle does not hamper that from empirical observations. As a consequence of the recent change not to link plugin initialization object files into static libraries, as well not having to compile the files in user projects, we can get rid of the _qt_internal_disable_static_default_plugins calls in various places. A side note. Consider a user static library (L) that links to a Qt static library (Gui) which provides plugins (platform plugins). If there is an executable (E) that links to (L), with no direct dependency to any other Qt module and the intention is that the executable will automatically get the platform plugin linked, then (L) needs to link PUBLIC-ly to (Gui) so that the plugin usage requirements are propagated successfully. This is a limitation of using target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which will propagate object files across static libraries only if qt_module is linked publicly. One could try to use target_link_libraries(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which preserves the linker arguments across static libs even if qt_module is linked privately, but unfortunately CMake will lose dependency information on Core, which means the object files might be placed in the wrong place on the link line. As far as I know this is a limitation of CMake that can't be worked around at the moment. Note this behavior was present before this change as well. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ia99e8aa3d32d6197cacd6162515ac808f2c6c53f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-11 09:19:19 +00:00
OBJECTS DESTINATION "${install_directory}"
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
ARCHIVE DESTINATION "${archive_install_directory}"
)
qt_install(EXPORT ${export_name}
NAMESPACE ${QT_CMAKE_EXPORT_NAMESPACE}::
DESTINATION "${config_install_dir}"
)
wasm: add cmake build support A few configure defines get changed: QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1 To create source maps for debugging. use device-option QT_WASM_SOURCE_MAP=1 Task-number: QTBUG-78647 Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-03 08:29:41 +00:00
if(BUILD_SHARED_LIBS)
qt_apply_rpaths(TARGET "${target}" INSTALL_PATH "${install_directory}" RELATIVE_RPATH)
CMake: Work around build rpath issue when CMAKE_STAGING_PREFIX is set CMake has logic to rewrite build rpaths that contain CMAKE_STAGING_PREFIX to instead point to CMAKE_INSTALL_PREFIX. This breaks running executables from the build directory, because their build rpath will point to a location where the libraries might not exist yet (we didn't install Qt yet). Work around this by setting CMAKE_STAGING_PREFIX to a fake path, so that CMake does not do the rewriting anymore. CMAKE_STAGING_PREFIX needs to be set at subdirectory scope, not function scope, which is why qt_internal_apply_staging_prefix_build_rpath_workaround() is a macro that is called from within each Qt internal function that creates a target. The workaround can be disabled by configuring with -DQT_NO_STAGING_PREFIX_BUILD_RPATH_WORKAROUND=ON The downside of this workaround is that it breaks per-subdirectory install rules like 'ninja src/gui/install'. Regular global installation like 'ninja install' works fine. This is similar to what we do for tests in qt_set_up_fake_standalone_tests_install_prefix() introduced by 20292250d44e08437306096e9096fc655cc9fb8b The reason it's not as good for other target types is because in contrast to tests, we do want to install them. In case if someone does call `ninja src/gui/install' they will most likely get a permission error, telling them it's not possible to install into /qt_fake_staging_prefix/ check_qt_internal_apply_staging_prefix_build_rpath_workaround Fixes: QTBUG-102592 Change-Id: I6ce78dde1924a8d830ef5c62808ff674c9639d65 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-04-14 16:04:41 +00:00
qt_internal_apply_staging_prefix_build_rpath_workaround()
wasm: add cmake build support A few configure defines get changed: QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1 To create source maps for debugging. use device-option QT_WASM_SOURCE_MAP=1 Task-number: QTBUG-78647 Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-03 08:29:41 +00:00
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endif()
if (NOT arg_ALLOW_UNDEFINED_SYMBOLS)
### fixme: cmake is missing a built-in variable for this. We want to apply it only to
# modules and plugins that belong to Qt.
qt_internal_add_link_flags_no_undefined("${target}")
endif()
qt_internal_add_linker_version_script(${target})
Fix plugin SKIP_INSTALL option If SKIP_INSTALL option is specified for the qt_internal_add_plugin function the install_directory variable become empty and finalizer unable to call qt_finalize_plugin, because of lack of the second argument. It makes sense to use the INSTALL_PATH single argument instead. Change-Id: I2d4b40c8cf812a834c0e045569b45a649d339508 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-26 14:52:43 +00:00
set(finalizer_extra_args "")
if(NOT arg_SKIP_INSTALL)
list(APPEND finalizer_extra_args INSTALL_PATH "${install_directory}")
endif()
qt_add_list_file_finalizer(qt_finalize_plugin ${target} ${finalizer_extra_args})
CMake Build: Enable separate debug info for all target types Now all shared libraries and executables will get .debug files on the platforms that support FEATURE_separate_debug_info With the directory property _qt_skip_separate_debug_info certain targets can retain the debug symbols in the binary e.g. lupdate with MinGW 8.1.0 will cause objcopy / strip to fail. Fixes: QTBUG-87015 Change-Id: I03b106e68ef0a42011d1ba641e6f686b2e7b7fb4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-02 11:40:57 +00:00
Fix plugin SKIP_INSTALL option If SKIP_INSTALL option is specified for the qt_internal_add_plugin function the install_directory variable become empty and finalizer unable to call qt_finalize_plugin, because of lack of the second argument. It makes sense to use the INSTALL_PATH single argument instead. Change-Id: I2d4b40c8cf812a834c0e045569b45a649d339508 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-26 14:52:43 +00:00
if(NOT arg_SKIP_INSTALL)
qt_enable_separate_debug_info(${target} "${install_directory}")
qt_internal_install_pdb_files(${target} "${install_directory}")
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endfunction()
Fix plugin SKIP_INSTALL option If SKIP_INSTALL option is specified for the qt_internal_add_plugin function the install_directory variable become empty and finalizer unable to call qt_finalize_plugin, because of lack of the second argument. It makes sense to use the INSTALL_PATH single argument instead. Change-Id: I2d4b40c8cf812a834c0e045569b45a649d339508 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-26 14:52:43 +00:00
function(qt_finalize_plugin target)
cmake_parse_arguments(arg "" "INSTALL_PATH" "" ${ARGN})
CMake: Add version information to Qt plugin DLLs Tools and library DLLs already have version information embedded. Add the missing _qt_internal_generate_win32_rc_file call for plugins. Fixes: QTBUG-87747 Change-Id: I619948f4066ce229d41e8b93f125751e1d28e26c Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-05 11:20:35 +00:00
if(WIN32 AND BUILD_SHARED_LIBS)
_qt_internal_generate_win32_rc_file("${target}")
endif()
cmake: Defer generating plugin .pri file until finalizer Allows adding additional properties to the target after the initial call to qt_internal_add_plugin. Change-Id: I7998c906e53699ec41b44b51aabbe480ae698b21 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-07 13:09:34 +00:00
# Generate .prl and .pri files for static plugins.
cmake: Generate prl and pri files for static plugins in shared Qt builds The CMake build system files are properly generated, but the qmake parts were missing. Change-Id: Icbcce3143db976c536c802ea2314bc3f2595da51 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-18 12:31:37 +00:00
get_target_property(target_type "${target}" TYPE)
if(target_type STREQUAL STATIC_LIBRARY)
Fix plugin SKIP_INSTALL option If SKIP_INSTALL option is specified for the qt_internal_add_plugin function the install_directory variable become empty and finalizer unable to call qt_finalize_plugin, because of lack of the second argument. It makes sense to use the INSTALL_PATH single argument instead. Change-Id: I2d4b40c8cf812a834c0e045569b45a649d339508 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-26 14:52:43 +00:00
if(arg_INSTALL_PATH)
qt_generate_prl_file(${target} "${arg_INSTALL_PATH}")
endif()
cmake: Defer generating plugin .pri file until finalizer Allows adding additional properties to the target after the initial call to qt_internal_add_plugin. Change-Id: I7998c906e53699ec41b44b51aabbe480ae698b21 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-07 13:09:34 +00:00
# There's no point in generating pri files for qml plugins.
# We didn't do it in Qt5 times.
get_target_property(plugin_type "${target}" QT_PLUGIN_TYPE)
if(NOT plugin_type STREQUAL "qml_plugin")
cmake: Move qt_install call into qt_generate_plugin_pri_file The same way qt_generate_module_pri_file does it. Change-Id: I42047ce7d23e8a289535041ccace8b0f0140ea12 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-07 13:40:58 +00:00
qt_generate_plugin_pri_file("${target}")
cmake: Defer generating plugin .pri file until finalizer Allows adding additional properties to the target after the initial call to qt_internal_add_plugin. Change-Id: I7998c906e53699ec41b44b51aabbe480ae698b21 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-07 13:09:34 +00:00
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endif()
endfunction()
function(qt_get_sanitized_plugin_type plugin_type out_var)
# Used to handle some edge cases such as platforms/darwin
string(REGEX REPLACE "[-/]" "_" plugin_type "${plugin_type}")
set("${out_var}" "${plugin_type}" PARENT_SCOPE)
endfunction()
# Utility function to find the module to which a plug-in belongs.
Make qt_get_module_for_plugin() internal and do what its name says Contrary to its name, this command was also setting a target property. Since it was only called in one place and that caller can just as easily set the property instead, rename the command to make clear its internal nature and refactor it so that the caller is responsible for setting that property instead. Also make it an error rather than just a warning if the command is used for a target that doesn't belong to any module. Since this is now unambiguously an internal command, we should always expect the target to belong to a module. Pick-to: 6.1 Change-Id: I929a652ddd482653868fc9df887f38f4bc7f35d9 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-03-01 06:17:54 +00:00
function(qt_internal_get_module_for_plugin target target_type out_var)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
qt_internal_get_qt_all_known_modules(known_modules)
qt_get_sanitized_plugin_type("${target_type}" target_type)
foreach(qt_module ${known_modules})
get_target_property(module_type "${QT_CMAKE_EXPORT_NAMESPACE}::${qt_module}" TYPE)
# Assuming interface libraries can't have plugins. Otherwise we'll need to fix the property
# name, because the current one would be invalid for interface libraries.
if(module_type STREQUAL "INTERFACE_LIBRARY")
continue()
endif()
get_target_property(plugin_types
"${QT_CMAKE_EXPORT_NAMESPACE}::${qt_module}"
MODULE_PLUGIN_TYPES)
Make qt_get_module_for_plugin() internal and do what its name says Contrary to its name, this command was also setting a target property. Since it was only called in one place and that caller can just as easily set the property instead, rename the command to make clear its internal nature and refactor it so that the caller is responsible for setting that property instead. Also make it an error rather than just a warning if the command is used for a target that doesn't belong to any module. Since this is now unambiguously an internal command, we should always expect the target to belong to a module. Pick-to: 6.1 Change-Id: I929a652ddd482653868fc9df887f38f4bc7f35d9 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-03-01 06:17:54 +00:00
if(plugin_types AND target_type IN_LIST plugin_types)
set("${out_var}" "${qt_module}" PARENT_SCOPE)
return()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endif()
endforeach()
Make qt_get_module_for_plugin() internal and do what its name says Contrary to its name, this command was also setting a target property. Since it was only called in one place and that caller can just as easily set the property instead, rename the command to make clear its internal nature and refactor it so that the caller is responsible for setting that property instead. Also make it an error rather than just a warning if the command is used for a target that doesn't belong to any module. Since this is now unambiguously an internal command, we should always expect the target to belong to a module. Pick-to: 6.1 Change-Id: I929a652ddd482653868fc9df887f38f4bc7f35d9 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-03-01 06:17:54 +00:00
message(FATAL_ERROR "The plug-in '${target}' does not belong to any Qt module.")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endfunction()
Add permission API backend for macOS and iOS When submitting applications to the iOS and macOS AppStore the application goes through static analysis, which will trigger on uses of various privacy protected APIs, unless the application has a corresponding usage description for the permission in the Info.plist file. This applies even if the application never requests the given permission, but just links to a Qt library that has the offending symbols or library dependencies. To ensure that the application does not have to add usage descriptions to their Info.plist for permissions they never plan to use we split up the various permission implementations into small static libraries that register with the Qt plugin mechanism as permission backends. We can then inspect the application's Info.plist at configure time and only add the relevant static permission libraries. Furthermore, since some permissions can be checked without any usage description, we allow the implementation to be split up into two separate translation units. By putting the request in its own translation unit we can selectively include it during linking by telling the linker to look for a special symbol. This is useful for libraries such as Qt Multimedia who would like to check the current permission status, but without needing to request any permission of its own. Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Change-Id: Ic2a43e1a0c45a91df6101020639f473ffd9454cc Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2022-05-10 13:02:43 +00:00
function(qt_internal_add_darwin_permission_plugin permission)
string(TOLOWER "${permission}" permission_lower)
string(TOUPPER "${permission}" permission_upper)
set(permission_source_file "platform/darwin/qdarwinpermissionplugin_${permission_lower}.mm")
set(plugin_target "QDarwin${permission}PermissionPlugin")
set(plugin_name "qdarwin${permission_lower}permission")
qt_internal_add_plugin(${plugin_target}
STATIC # Force static, even in shared builds
OUTPUT_NAME ${plugin_name}
PLUGIN_TYPE permissions
DEFAULT_IF FALSE
SOURCES
${permission_source_file}
DEFINES
QT_DARWIN_PERMISSION_PLUGIN=${permission}
LIBRARIES
Qt::Core
Qt::CorePrivate
macOS: Add dependency to Foundation for permission plugins Fixes: QTBUG-108270 Change-Id: Ic09c3422d2006e18ab355af564ac1bb3f24318c2 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Juha Vuolle <juha.vuolle@insta.fi>
2022-11-08 14:12:14 +00:00
${FWFoundation}
Add permission API backend for macOS and iOS When submitting applications to the iOS and macOS AppStore the application goes through static analysis, which will trigger on uses of various privacy protected APIs, unless the application has a corresponding usage description for the permission in the Info.plist file. This applies even if the application never requests the given permission, but just links to a Qt library that has the offending symbols or library dependencies. To ensure that the application does not have to add usage descriptions to their Info.plist for permissions they never plan to use we split up the various permission implementations into small static libraries that register with the Qt plugin mechanism as permission backends. We can then inspect the application's Info.plist at configure time and only add the relevant static permission libraries. Furthermore, since some permissions can be checked without any usage description, we allow the implementation to be split up into two separate translation units. By putting the request in its own translation unit we can selectively include it during linking by telling the linker to look for a special symbol. This is useful for libraries such as Qt Multimedia who would like to check the current permission status, but without needing to request any permission of its own. Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Change-Id: Ic2a43e1a0c45a91df6101020639f473ffd9454cc Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2022-05-10 13:02:43 +00:00
)
# Disable PCH since CMake falls over on single .mm source targets
set_target_properties(${plugin_target} PROPERTIES
DISABLE_PRECOMPILE_HEADERS ON
)
# Generate plugin JSON file
set(content "{ \"Permissions\": [ \"Q${permission}Permission\" ] }")
get_target_property(plugin_build_dir "${plugin_target}" BINARY_DIR)
set(output_file "${plugin_build_dir}/${plugin_target}.json")
qt_configure_file(OUTPUT "${output_file}" CONTENT "${content}")
# Associate required usage descriptions
set(usage_descriptions_property "_qt_info_plist_usage_descriptions")
set_target_properties(${plugin_target} PROPERTIES
${usage_descriptions_property} "NS${permission}UsageDescription"
)
set_property(TARGET ${plugin_target} APPEND PROPERTY
EXPORT_PROPERTIES ${usage_descriptions_property}
)
set(usage_descriptions_genex "$<JOIN:$<TARGET_PROPERTY:${plugin_target},${usage_descriptions_property}>, >")
set(extra_plugin_pri_content
"QT_PLUGIN.${plugin_name}.usage_descriptions = ${usage_descriptions_genex}"
)
# Support granular check and request implementations
set(separate_request_source_file
"${plugin_build_dir}/qdarwinpermissionplugin_${permission_lower}_request.mm")
set(separate_request_genex
"$<BOOL:$<TARGET_PROPERTY:${plugin_target},_qt_darwin_permissison_separate_request>>")
file(GENERATE OUTPUT "${separate_request_source_file}" CONTENT
"
#define BUILDING_PERMISSION_REQUEST 1
#include \"${CMAKE_CURRENT_SOURCE_DIR}/${permission_source_file}\"
"
CONDITION "${separate_request_genex}"
)
Fix macOS build for CMake < 3.18 We must explicitly set the GENERATED property on source files we generate. This amends commit f0a7d74e1dd2c1d802aa09d7b8c144599f4a54ce. Change-Id: Ifab405cd98deece49a1566ae04220e2b5d576429 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-17 10:38:48 +00:00
if(CMAKE_VERSION VERSION_LESS "3.18")
set_property(SOURCE "${separate_request_source_file}" PROPERTY GENERATED TRUE)
endif()
Add permission API backend for macOS and iOS When submitting applications to the iOS and macOS AppStore the application goes through static analysis, which will trigger on uses of various privacy protected APIs, unless the application has a corresponding usage description for the permission in the Info.plist file. This applies even if the application never requests the given permission, but just links to a Qt library that has the offending symbols or library dependencies. To ensure that the application does not have to add usage descriptions to their Info.plist for permissions they never plan to use we split up the various permission implementations into small static libraries that register with the Qt plugin mechanism as permission backends. We can then inspect the application's Info.plist at configure time and only add the relevant static permission libraries. Furthermore, since some permissions can be checked without any usage description, we allow the implementation to be split up into two separate translation units. By putting the request in its own translation unit we can selectively include it during linking by telling the linker to look for a special symbol. This is useful for libraries such as Qt Multimedia who would like to check the current permission status, but without needing to request any permission of its own. Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Change-Id: Ic2a43e1a0c45a91df6101020639f473ffd9454cc Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2022-05-10 13:02:43 +00:00
target_sources(${plugin_target} PRIVATE
"$<${separate_request_genex}:${separate_request_source_file}>"
)
set_property(TARGET ${plugin_target} APPEND PROPERTY
EXPORT_PROPERTIES _qt_darwin_permissison_separate_request
)
set(permission_request_symbol "_QDarwin${permission}PermissionRequest")
set(permission_request_flag "-Wl,-u,${permission_request_symbol}")
set(has_usage_description_property "_qt_has_${plugin_target}_usage_description")
set(has_usage_description_genex "$<BOOL:$<TARGET_PROPERTY:${has_usage_description_property}>>")
target_link_options(${plugin_target} INTERFACE
"$<$<AND:${separate_request_genex},${has_usage_description_genex}>:${permission_request_flag}>")
list(APPEND extra_plugin_pri_content
"QT_PLUGIN.${plugin_name}.request_flag = $<${separate_request_genex}:${permission_request_flag}>"
)
# Expose properties to qmake
set_property(TARGET ${plugin_target} PROPERTY
QT_PLUGIN_PRI_EXTRA_CONTENT ${extra_plugin_pri_content}
)
endfunction()
Reference in New Issue Copy Permalink