AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
63db26a47e
qt5base-lts/cmake/QtPublicPluginHelpers.cmake

486 lines
19 KiB
CMake
Raw Normal View History

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
# Gets the qt plugin type of the given plugin into out_var_plugin_type.
# Also sets out_var_has_plugin_type to TRUE or FALSE depending on whether the plugin type was found.
CMake: Refactor handling of static plugins Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 13:25:18 +00:00
function(__qt_internal_plugin_get_plugin_type
plugin_target
out_var_has_plugin_type
out_var_plugin_type)
set(has_plugin_type TRUE)
set(plugin_target_versioned "${QT_CMAKE_EXPORT_NAMESPACE}::${plugin_target}")
get_target_property(_plugin_type "${plugin_target_versioned}" QT_PLUGIN_TYPE)
if(NOT _plugin_type)
message("Warning: plugin ${plugin_target_versioned} has no plugin type set, skipping.")
set(has_plugin_type FALSE)
else()
set(${out_var_plugin_type} "${_plugin_type}" PARENT_SCOPE)
endif()
set(${out_var_has_plugin_type} "${has_plugin_type}" PARENT_SCOPE)
endfunction()
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
# Gets the qt plugin class name of the given target into out_var.
CMake: Refactor handling of static plugins Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 13:25:18 +00:00
function(__qt_internal_plugin_has_class_name plugin_target out_var)
set(plugin_target_versioned "${QT_CMAKE_EXPORT_NAMESPACE}::${plugin_target}")
get_target_property(classname "${plugin_target_versioned}" QT_PLUGIN_CLASS_NAME)
if(NOT classname)
message("Warning: plugin ${plugin_target_versioned} has no class name, skipping.")
endif()
# If unset, it will be -NOTFOUND and still evaluate to false.
set(${out_var} "${classname}" PARENT_SCOPE)
endfunction()
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
# Constructs a generator expression which decides whether a plugin will be used.
#
# The conditions are based on the various properties set in qt_import_plugins.
# All the TARGET_PROPERTY genexes are evaluated in the context of the currently linked target.
#
# The genex is saved into out_var.
CMake: Refactor handling of static plugins Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 13:25:18 +00:00
function(__qt_internal_get_static_plugin_condition_genex
plugin_target_unprefixed
out_var)
set(plugin_target "${QT_CMAKE_EXPORT_NAMESPACE}::${plugin_target_unprefixed}")
set(plugin_target_versionless "Qt::${plugin_target_unprefixed}")
get_target_property(_plugin_type "${plugin_target}" QT_PLUGIN_TYPE)
set(_default_plugins_are_enabled
"$<NOT:$<STREQUAL:$<GENEX_EVAL:$<TARGET_PROPERTY:QT_DEFAULT_PLUGINS>>,0>>")
set(_manual_plugins_genex "$<GENEX_EVAL:$<TARGET_PROPERTY:QT_PLUGINS>>")
set(_no_plugins_genex "$<GENEX_EVAL:$<TARGET_PROPERTY:QT_NO_PLUGINS>>")
# Plugin genex marker for prl processing.
set(_is_plugin_marker_genex "$<BOOL:QT_IS_PLUGIN_GENEX>")
set(_plugin_is_default "$<TARGET_PROPERTY:${plugin_target},QT_DEFAULT_PLUGIN>")
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
# The code in here uses the properties defined in qt_import_plugins (Qt6CoreMacros.cmake)
CMake: Refactor handling of static plugins Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 13:25:18 +00:00
# INCLUDE
set(_plugin_is_whitelisted "$<IN_LIST:${plugin_target},${_manual_plugins_genex}>")
set(_plugin_versionless_is_whitelisted
"$<IN_LIST:${plugin_target_versionless},${_manual_plugins_genex}>")
# Note: qt_import_plugins sets the QT_PLUGINS_${_plugin_type} to "-"
# when excluding it with EXCLUDE_BY_TYPE,
# which ensures that no plug-in will be supported unless explicitly re-added afterwards.
string(CONCAT _plugin_is_not_blacklisted
"$<AND:"
"$<NOT:" # EXCLUDE
"$<IN_LIST:${plugin_target},${_no_plugins_genex}>"
">,"
"$<NOT:"
"$<IN_LIST:${plugin_target_versionless},${_no_plugins_genex}>"
">,"
# Excludes both plugins targeted by EXCLUDE_BY_TYPE and not included in
# INCLUDE_BY_TYPE.
"$<STREQUAL:,$<GENEX_EVAL:$<TARGET_PROPERTY:QT_PLUGINS_${_plugin_type}>>>"
">"
)
# Support INCLUDE_BY_TYPE
string(CONCAT _plugin_is_in_type_whitelist
"$<IN_LIST:"
"${plugin_target},"
"$<GENEX_EVAL:"
"$<TARGET_PROPERTY:QT_PLUGINS_${_plugin_type}>"
">"
">"
)
string(CONCAT _plugin_versionless_is_in_type_whitelist
"$<IN_LIST:"
"${plugin_target_versionless},"
"$<GENEX_EVAL:"
"$<TARGET_PROPERTY:QT_PLUGINS_${_plugin_type}>"
">"
">"
)
CMake: Don't do plugin initialization for static libraries Q_IMPORT_PLUGIN generates a global static symbol that initializes a plugin. If this symbol is added to a static library and the library is then linked to an executable, the linker decides that the symbol is unused (because nothing references it) and discards it. This means there's no point to compile the Q_IMPORT_PLUGIN containing files into static libraries. Change the generator expression we use for plugin propagation via associated modules to not compile and link the plugin initialization object file into a static library. Pick-to: 6.1 Task-number: QTBUG-80863 Change-Id: Ide32c0124c1e313c352a72280ce32ce9fbe8fff1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-12 07:42:41 +00:00
# No point in linking the plugin initialization source file into static libraries. The
# initialization symbol will be discarded by the linker when the static lib is linked into an
# executable or shared library, because nothing is referencing the global static symbol.
set(type_genex "$<TARGET_PROPERTY:TYPE>")
set(no_static_genex "$<NOT:$<STREQUAL:${type_genex},STATIC_LIBRARY>>")
CMake: Refactor handling of static plugins Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 13:25:18 +00:00
# Complete condition that defines whether a static plugin is linked
string(CONCAT _plugin_condition
"$<BOOL:$<AND:"
"${_is_plugin_marker_genex},"
CMake: Don't do plugin initialization for static libraries Q_IMPORT_PLUGIN generates a global static symbol that initializes a plugin. If this symbol is added to a static library and the library is then linked to an executable, the linker decides that the symbol is unused (because nothing references it) and discards it. This means there's no point to compile the Q_IMPORT_PLUGIN containing files into static libraries. Change the generator expression we use for plugin propagation via associated modules to not compile and link the plugin initialization object file into a static library. Pick-to: 6.1 Task-number: QTBUG-80863 Change-Id: Ide32c0124c1e313c352a72280ce32ce9fbe8fff1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-12 07:42:41 +00:00
"${no_static_genex},"
CMake: Refactor handling of static plugins Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 13:25:18 +00:00
"$<OR:"
"${_plugin_is_whitelisted},"
"${_plugin_versionless_is_whitelisted},"
"${_plugin_is_in_type_whitelist},"
"${_plugin_versionless_is_in_type_whitelist},"
"$<AND:"
"${_default_plugins_are_enabled},"
"${_plugin_is_default},"
"${_plugin_is_not_blacklisted}"
">"
">"
">>"
)
set(${out_var} "${_plugin_condition}" PARENT_SCOPE)
endfunction()
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
# Wraps the genex condition to evaluate to true only when using the regular plugin importing mode
# (not finalizer mode).
function(__qt_internal_get_plugin_condition_regular_mode plugin_condition out_var)
CMake: Remove qt6_enable_object_libraries_finalizer_mode qt6_enable_object_libraries_finalizer_mode is not needed anymore now that static Qt builds require CMake 3.21 and thus CMake takes care of placing object library object files at the beginning of the link line. Rename qt6_enable_import_plugins_finalizer_mode to a more generic qt6_set_finalizer_mode that can enable or disable multiple different modes. For now the only available mode is "static_plugins" which handles the behavior of the old function name. The mode can be enabled by calling qt6_set_finalizer_mode(${target} ENABLE MODES "static_plugins") Note that the function is re-tagged as being in Technical Preview. Ideally we would not need it at all. But we need to provide some workaround for the limitations of linking Qt static plugins in CMake on Linux-y platforms that use bfd ld or ld.gold. The workaround does not work well with dependencies wrapped in generator expressions which is why we can't confidently advertise it as a proper solution. Our hope is that this can be fixed in future upstream CMake versions and the function can be removed. See 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 for details. Adjust the tests due to the renamed and removed functions. Amends 19e789bace887105badae83c0a79429bbf8e8221 Amends cdbb390c4a9b8d53cfcfd0884e6720423ce5e126 Amends a25027eecb3829a65543d0e8ab00c74e1b1a21c5 Amends 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 Amends a3c430f390b379d874916d4c9ff02af5323af1bd Pick-to: 6.2 Fixes: QTBUG-95169 Task-number: QTBUG-95601 Task-number: QTBUG-95603 Change-Id: I51b85f776ec29fc04fed1a637eba7d1f60609e69 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-05 14:49:42 +00:00
set(not_finalizer_mode "$<NOT:$<BOOL:$<TARGET_PROPERTY:_qt_static_plugins_finalizer_mode>>>")
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
set(full_plugin_condition "$<AND:${plugin_condition},${not_finalizer_mode}>")
set(${out_var} "${full_plugin_condition}" PARENT_SCOPE)
endfunction()
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
# Link plugin via usage requirements of associated Qt module.
CMake: Refactor handling of static plugins Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 13:25:18 +00:00
function(__qt_internal_add_static_plugin_linkage plugin_target qt_module_target)
__qt_internal_get_static_plugin_condition_genex("${plugin_target}" plugin_condition)
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
__qt_internal_get_plugin_condition_regular_mode("${plugin_condition}" full_plugin_condition)
CMake: Refactor handling of static plugins Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 13:25:18 +00:00
set(plugin_target "${QT_CMAKE_EXPORT_NAMESPACE}::${plugin_target}")
# If this condition is true, we link against the plug-in
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
set(plugin_genex "$<${full_plugin_condition}:${plugin_target}>")
CMake: Refactor handling of static plugins Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 13:25:18 +00:00
target_link_libraries(${qt_module_target} INTERFACE "${plugin_genex}")
endfunction()
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
# Generates C++ import macro source code for given plugin
function(__qt_internal_get_plugin_import_macro plugin_target out_var)
CMake: Set the plugin class name for qml plugins This is needed for a change in qtdeclarative to allow building the Q_IMPORT_PLUGIN-containing object library initializer of a qml plugin. Show an error if the qml plugin has no class name, it's needed for plugin initialization so it's mandatory to have a class name. Show an error if a class name is not found when computing the import macro for a plugin (both for a regular qt plugin and a qml plugin). When querying for the class name of a target, query both a Qt6:: prefixed target as well as a non-prefixed one, with the Qt one taking precedence. This is to allow querying the class name of user project created qml plugins. Currently regular qt user plugins don't use the object library initializer approach. This will likely be revisited in the future. Pick-to: 6.2 Task-number: QTBUG-92933 Change-Id: I46417471a7d8b49651e6821f7b28e7a9d44c2557 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-11 15:02:45 +00:00
set(plugin_target_prefixed "${QT_CMAKE_EXPORT_NAMESPACE}::${plugin_target}")
# Query the class name of plugin targets prefixed with a Qt namespace and without, this is
# needed to support plugin object initializers created by user projects.
set(class_name"")
set(class_name_prefixed "")
if(TARGET ${plugin_target})
get_target_property(class_name "${plugin_target}" QT_PLUGIN_CLASS_NAME)
endif()
if(TARGET ${plugin_target_prefixed})
get_target_property(class_name_prefixed "${plugin_target_prefixed}" QT_PLUGIN_CLASS_NAME)
endif()
if(NOT class_name AND NOT class_name_prefixed)
message(FATAL_ERROR "No QT_PLUGIN_CLASS_NAME value on target: '${plugin_target}'")
endif()
# Qt prefixed target takes priority.
if(class_name_prefixed)
set(class_name "${class_name_prefixed}")
endif()
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
set(${out_var} "Q_IMPORT_PLUGIN(${class_name})" PARENT_SCOPE)
endfunction()
function(__qt_internal_get_plugin_include_prelude out_var)
set(${out_var} "#include <QtPlugin>\n" PARENT_SCOPE)
endfunction()
# Set up plugin initialization via usage requirements of associated Qt module.
#
# Adds the plugin init object library as an INTERFACE source of the plugin target.
# This is similar to how it was done before, except instead of generating a C++ file and compiling
# it as part of the user project, we just specify the pre-compiled object file as an INTERFACE
# source so that user projects don't have to compile it. User project builds will thus be shorter.
CMake: Refactor handling of static plugins Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 13:25:18 +00:00
function(__qt_internal_add_static_plugin_import_macro
plugin_target
qt_module_target
qt_module_unprefixed)
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_internal_get_static_plugin_init_target_name("${plugin_target}" plugin_init_target)
CMake: Use __qt_internal_propagate_object_library for static plugins Address TODO and use the new helper __qt_internal_propagate_object_library function instead of target_sources when linking static plugin initializers via usage requirements. Note that to work correctly this depends on using the target_link_options object library linking approach, which means a minimum CMake version of 3.17, which is already the case for static Qt usage. With CMake 3.21, it will use target_link_libraries approach instead. With CMake version 3.16 or lower, currently, this won't work correctly on Linux if there are dependencies wrapped in genexes because the __qt_internal_propagate_object_library call will try to use the still-by-default-enabled 'object_libraries' finalizer mode via __qt_internal_collect_dependency_object_libraries and that stops the usage of the target_sources approach to link the object files directly. This isn't a big deal though, because we already require CMake 3.20 as the minimum. It might be a bigger deal if we will need any of this functionality to work with 3.16 in shared Qt builds where the user project tries to create and link against custom static plugins. But that's already likely to be a can of worms even without this specific edge case. Amends a37957df5c1d3d8624fae2222734a127ec340a72 Amends 91c65dd80cdd2de666448c14202c0c63718152b6 Uses 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Task-number: QTBUG-92933 Change-Id: I8710e79eee265d820f65c8ccc3d0bd0c0ee6eccd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-06 13:51:52 +00:00
set(plugin_init_target_namespaced "${QT_CMAKE_EXPORT_NAMESPACE}::${plugin_init_target}")
CMake: Refactor handling of static plugins Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 13:25:18 +00:00
CMake: Use __qt_internal_propagate_object_library for static plugins Address TODO and use the new helper __qt_internal_propagate_object_library function instead of target_sources when linking static plugin initializers via usage requirements. Note that to work correctly this depends on using the target_link_options object library linking approach, which means a minimum CMake version of 3.17, which is already the case for static Qt usage. With CMake 3.21, it will use target_link_libraries approach instead. With CMake version 3.16 or lower, currently, this won't work correctly on Linux if there are dependencies wrapped in genexes because the __qt_internal_propagate_object_library call will try to use the still-by-default-enabled 'object_libraries' finalizer mode via __qt_internal_collect_dependency_object_libraries and that stops the usage of the target_sources approach to link the object files directly. This isn't a big deal though, because we already require CMake 3.20 as the minimum. It might be a bigger deal if we will need any of this functionality to work with 3.16 in shared Qt builds where the user project tries to create and link against custom static plugins. But that's already likely to be a can of worms even without this specific edge case. Amends a37957df5c1d3d8624fae2222734a127ec340a72 Amends 91c65dd80cdd2de666448c14202c0c63718152b6 Uses 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Task-number: QTBUG-92933 Change-Id: I8710e79eee265d820f65c8ccc3d0bd0c0ee6eccd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-06 13:51:52 +00:00
__qt_internal_propagate_object_library(
"${QT_CMAKE_EXPORT_NAMESPACE}::${plugin_target}"
"${plugin_init_target_namespaced}"
Avoid implicit linking of plugin init library if finalizers were called Propagating of plugin init libraries should take into account plugin finalizers to avoid duplicating of object files in a linker line. Pick-to: 6.2 Fixes: QTBUG-96062 Change-Id: I48feac94b08a7eb08d84134e9e9ae6e7214f5bdd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-07 17:42:49 +00:00
EXTRA_CONDITIONS
"$<NOT:$<BOOL:$<TARGET_PROPERTY:_qt_static_plugins_finalizer_mode>>>"
CMake: Use __qt_internal_propagate_object_library for static plugins Address TODO and use the new helper __qt_internal_propagate_object_library function instead of target_sources when linking static plugin initializers via usage requirements. Note that to work correctly this depends on using the target_link_options object library linking approach, which means a minimum CMake version of 3.17, which is already the case for static Qt usage. With CMake 3.21, it will use target_link_libraries approach instead. With CMake version 3.16 or lower, currently, this won't work correctly on Linux if there are dependencies wrapped in genexes because the __qt_internal_propagate_object_library call will try to use the still-by-default-enabled 'object_libraries' finalizer mode via __qt_internal_collect_dependency_object_libraries and that stops the usage of the target_sources approach to link the object files directly. This isn't a big deal though, because we already require CMake 3.20 as the minimum. It might be a bigger deal if we will need any of this functionality to work with 3.16 in shared Qt builds where the user project tries to create and link against custom static plugins. But that's already likely to be a can of worms even without this specific edge case. Amends a37957df5c1d3d8624fae2222734a127ec340a72 Amends 91c65dd80cdd2de666448c14202c0c63718152b6 Uses 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Task-number: QTBUG-92933 Change-Id: I8710e79eee265d820f65c8ccc3d0bd0c0ee6eccd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-06 13:51:52 +00:00
)
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
endfunction()
CMake: Refactor handling of static plugins Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 13:25:18 +00:00
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
# Get target name of object library which is used to initialize a qt plugin.
function(__qt_internal_get_static_plugin_init_target_name plugin_target out_var)
# Keep the target name short, so we don't hit long path issues on Windows.
set(plugin_init_target "${plugin_target}_init")
CMake: Refactor handling of static plugins Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 13:25:18 +00:00
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
set(${out_var} "${plugin_init_target}" PARENT_SCOPE)
CMake: Refactor handling of static plugins Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 13:25:18 +00:00
endfunction()
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
# Create an object library that initializes a static qt plugin.
#
# The object library contains a single generated C++ file that calls Q_IMPORT_PLUGIN(plugin_class).
# The object library is exported as part of the Qt build and consumed by user applications
# that link to qt plugins.
#
# The created target name is assigned to 'out_var_plugin_init_target'.
function(__qt_internal_add_static_plugin_init_object_library
plugin_target
out_var_plugin_init_target)
__qt_internal_get_plugin_import_macro(${plugin_target} import_macro)
__qt_internal_get_plugin_include_prelude(include_prelude)
set(import_content "${include_prelude}${import_macro}")
string(MAKE_C_IDENTIFIER "${plugin_target}" plugin_target_identifier)
set(generated_qt_plugin_file_name
"${CMAKE_CURRENT_BINARY_DIR}/${plugin_target_identifier}_init.cpp")
file(GENERATE
OUTPUT "${generated_qt_plugin_file_name}"
CONTENT "${import_content}"
)
CMake: Fix 'Cannot find source file' error with older CMakes Configuring a static plugin init library with CMake versions earlier than 3.18.0 fails at generation phase with CMake Error at Qt6CoreMacros.cmake:2071 (add_library): Cannot find source file: example/plugins/basictools/pnp_basictools_init.cpp Call Stack (most recent call first): qtbase/lib/cmake/Qt6Core/Qt6CoreMacros.cmake:1998 (_qt_internal_add_library) qtbase/lib/cmake/Qt6/QtPublicPluginHelpers.cmake:243 (qt6_add_library) qtbase/lib/cmake/Qt6Core/Qt6CoreMacros.cmake:1967 (__qt_internal_add_static_plugin_init_object_library) qtbase/lib/cmake/Qt6Core/Qt6CoreMacros.cmake:1989 (qt6_add_plugin) qtbase/plugins/basictools/CMakeLists.txt:1 (qt_add_plugin) Marking the generated file as GENERATED explicitly solves the issue. Similar to e2c6f2ba7ed72195d12e9882c174e59a53317097 Fixes: QTBUG-96197 Pick-to: 6.2 Change-Id: If730a1fcbe6910d6041eb6eba03d6e45a025c424 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-03 15:35:59 +00:00
# CMake versions earlier than 3.18.0 can't find the generated file for some reason,
# failing at generation phase.
# Explicitly marking the file as GENERATED fixes the issue.
set_source_files_properties("${generated_qt_plugin_file_name}" PROPERTIES GENERATED TRUE)
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_internal_get_static_plugin_init_target_name("${plugin_target}" plugin_init_target)
Avoid to call _qt_internal_set_up_static_runtime_library() twice Pick-to: 6.2 Change-Id: I28985470b3e0b88befbbd2d62a027670d7d6c822 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-02 10:16:38 +00:00
qt6_add_library("${plugin_init_target}" OBJECT "${generated_qt_plugin_file_name}")
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
target_link_libraries(${plugin_init_target}
PRIVATE
# Core provides the symbols needed by Q_IMPORT_PLUGIN.
${QT_CMAKE_EXPORT_NAMESPACE}::Core
)
CMake: Export info if an object lib target is a plugin initializer Needed for qtdeclarative so we can filter out which object library should go into which export set, because qt_internal_add_qml_module can create both a backing library export set and a plugin export set. The plugin initializer object lib should go to the plugin export set. Pick-to: 6.2 Task-number: QTBUG-92933 Change-Id: I0fce131eff75a0b3090ac0fbb2a12ecfcba5e38d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-16 15:56:07 +00:00
set_property(TARGET ${plugin_init_target} PROPERTY _is_qt_plugin_init_target TRUE)
set_property(TARGET ${plugin_init_target} APPEND PROPERTY
EXPORT_PROPERTIES _is_qt_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
set(${out_var_plugin_init_target} "${plugin_init_target}" PARENT_SCOPE)
endfunction()
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
# Collect a list of genexes to link plugin libraries.
function(__qt_internal_collect_plugin_libraries plugin_targets out_var)
set(plugins_to_link "")
foreach(plugin_target ${plugin_targets})
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}::${plugin_target}")
get_target_property(type "${plugin_target_versioned}" TYPE)
if(NOT type STREQUAL STATIC_LIBRARY)
continue()
endif()
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
__qt_internal_get_static_plugin_condition_genex(
"${plugin_target}"
plugin_condition)
list(APPEND plugins_to_link "$<${plugin_condition}:${plugin_target_versioned}>")
endforeach()
set("${out_var}" "${plugins_to_link}" PARENT_SCOPE)
endfunction()
# Collect a list of genexes to link plugin initializer object libraries.
#
# The object libraries are only linked if the associated plugins are linked.
function(__qt_internal_collect_plugin_init_libraries plugin_targets out_var)
set(plugin_inits_to_link "")
foreach(plugin_target ${plugin_targets})
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}::${plugin_target}")
get_target_property(type "${plugin_target_versioned}" TYPE)
if(NOT type STREQUAL STATIC_LIBRARY)
continue()
endif()
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
__qt_internal_get_static_plugin_condition_genex(
"${plugin_target}"
plugin_condition)
__qt_internal_get_static_plugin_init_target_name("${plugin_target}" plugin_init_target)
set(plugin_init_target_versioned "${QT_CMAKE_EXPORT_NAMESPACE}::${plugin_init_target}")
list(APPEND plugin_inits_to_link "$<${plugin_condition}:${plugin_init_target_versioned}>")
endforeach()
set("${out_var}" "${plugin_inits_to_link}" PARENT_SCOPE)
endfunction()
# Collects all plugin targets discovered by walking the dependencies of ${target}.
#
# Walks immediate dependencies and their transitive dependencies.
# Plugins are collected by inspecting the _qt_plugins property found on any dependency Qt target.
function(__qt_internal_collect_plugin_targets_from_dependencies target out_var)
set(dep_targets "")
__qt_internal_collect_all_target_dependencies("${target}" dep_targets)
set(plugin_targets "")
foreach(dep_target ${dep_targets})
get_target_property(plugins ${dep_target} _qt_plugins)
if(plugins)
list(APPEND plugin_targets ${plugins})
endif()
endforeach()
# Plugins that are specified via qt_import_plugin's INCLUDE or INCLUDE_BY_TYPE can have
# dependencies on Qt modules. These modules in turn might bring in more default plugins to link
# So it's recursive. Do only one pass for now. Try to extract the included static plugins, walk
# their public and private dependencies, check if any of them are Qt modules that provide more
# plugins and extract the target names of those plugins.
__qt_internal_collect_plugin_targets_from_dependencies_of_plugins(
"${target}" recursive_plugin_targets)
if(recursive_plugin_targets)
list(APPEND plugin_targets ${recursive_plugin_targets})
endif()
list(REMOVE_DUPLICATES plugin_targets)
set("${out_var}" "${plugin_targets}" PARENT_SCOPE)
endfunction()
# Helper to collect plugin targets from encountered module dependencies as a result of walking
# dependencies. These module dependencies might expose additional plugins.
function(__qt_internal_collect_plugin_targets_from_dependencies_of_plugins target out_var)
set(assigned_plugins_overall "")
get_target_property(assigned_qt_plugins "${target}" QT_PLUGINS)
if(assigned_qt_plugins)
foreach(assigned_qt_plugin ${assigned_qt_plugins})
if(TARGET "${assigned_qt_plugin}")
list(APPEND assigned_plugins_overall "${assigned_qt_plugin}")
endif()
endforeach()
endif()
get_target_property(assigned_qt_plugins_by_type "${target}" _qt_plugins_by_type)
if(assigned_qt_plugins_by_type)
foreach(assigned_qt_plugin ${assigned_qt_plugins_by_type})
if(TARGET "${assigned_qt_plugin}")
list(APPEND assigned_plugins_overall "${assigned_qt_plugin}")
endif()
endforeach()
endif()
set(plugin_targets "")
foreach(target ${assigned_plugins_overall})
__qt_internal_walk_libs(
"${target}"
dep_targets
_discarded_out_var
"qt_private_link_library_targets"
"collect_targets")
foreach(dep_target ${dep_targets})
get_target_property(plugins ${dep_target} _qt_plugins)
if(plugins)
list(APPEND plugin_targets ${plugins})
endif()
endforeach()
endforeach()
list(REMOVE_DUPLICATES plugin_targets)
set("${out_var}" "${plugin_targets}" PARENT_SCOPE)
endfunction()
# Main logic of finalizer mode.
function(__qt_internal_apply_plugin_imports_finalizer_mode target)
# Process a target only once.
get_target_property(processed ${target} _qt_plugin_finalizer_imports_processed)
if(processed)
return()
endif()
# By default if the project hasn't explicitly opted in or out, use finalizer mode.
CMake: Revise plugin finalizer mode usage Only use plugin finalizer mode if qt_finalize_target is called at the end of the user project (which we can't really check, the user has to ensure that) or when qt_finalize_target is automatically defer-called by CMake 3.19+ (which is done by qt_add_executable). This removes the previous behavior of using the finalizer mode if qt_import_plugins is called. Instead the old regular mode is used if the above preconditions are not met. The removed behavior had ordering issues if qt_import_plugins was called before target_link_libraries. The dependency walking would be done before Qt dependencies were added and thus no plugins would be linked. Amends 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 Task-number: QTBUG-80863 Task-number: QTBUG-92933 Task-number: QTBUG-94030 Change-Id: I78702b653a35596f5581c2f4282b2336f0124e60 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-26 15:19:08 +00:00
# The precondition for this is that qt_finalize_target was called (either explicitly by the user
# or auto-deferred by CMake 3.19+).
CMake: Remove qt6_enable_object_libraries_finalizer_mode qt6_enable_object_libraries_finalizer_mode is not needed anymore now that static Qt builds require CMake 3.21 and thus CMake takes care of placing object library object files at the beginning of the link line. Rename qt6_enable_import_plugins_finalizer_mode to a more generic qt6_set_finalizer_mode that can enable or disable multiple different modes. For now the only available mode is "static_plugins" which handles the behavior of the old function name. The mode can be enabled by calling qt6_set_finalizer_mode(${target} ENABLE MODES "static_plugins") Note that the function is re-tagged as being in Technical Preview. Ideally we would not need it at all. But we need to provide some workaround for the limitations of linking Qt static plugins in CMake on Linux-y platforms that use bfd ld or ld.gold. The workaround does not work well with dependencies wrapped in generator expressions which is why we can't confidently advertise it as a proper solution. Our hope is that this can be fixed in future upstream CMake versions and the function can be removed. See 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 for details. Adjust the tests due to the renamed and removed functions. Amends 19e789bace887105badae83c0a79429bbf8e8221 Amends cdbb390c4a9b8d53cfcfd0884e6720423ce5e126 Amends a25027eecb3829a65543d0e8ab00c74e1b1a21c5 Amends 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 Amends a3c430f390b379d874916d4c9ff02af5323af1bd Pick-to: 6.2 Fixes: QTBUG-95169 Task-number: QTBUG-95601 Task-number: QTBUG-95603 Change-Id: I51b85f776ec29fc04fed1a637eba7d1f60609e69 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-05 14:49:42 +00:00
__qt_internal_check_finalizer_mode("${target}"
use_finalizer_mode
static_plugins
DEFAULT_VALUE "TRUE"
)
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
if(NOT use_finalizer_mode)
return()
endif()
__qt_internal_collect_plugin_targets_from_dependencies("${target}" plugin_targets)
__qt_internal_collect_plugin_init_libraries("${plugin_targets}" init_libraries)
__qt_internal_collect_plugin_libraries("${plugin_targets}" plugin_libraries)
target_link_libraries(${target} PRIVATE "${plugin_libraries}" "${init_libraries}")
set_target_properties(${target} PROPERTIES _qt_plugin_finalizer_imports_processed TRUE)
endfunction()
CMake: Move plugin package inclusion logic into a common function Don't duplicate the logic of plugin package inclusion for each Qt module. Instead move it into QtPublicPluginHelpers.cmake. Pick-to: 6.4 Task-number: QTBUG-94066 Change-Id: I5e1f5176a0e754ed56a792c97865752529462617 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-01 12:29:25 +00:00
# Include CMake plugin packages that belong to the Qt module ${target} and initialize automatic
# linkage of the plugins in static builds.
function(__qt_internal_include_plugin_packages target)
set(_module_target "${QT_CMAKE_EXPORT_NAMESPACE}::${target}")
set(_qt_plugins "")
# Properties can't be set on aliased targets, so make sure to unalias the target. This is needed
# when Qt examples are built as part of the Qt build itself.
get_target_property(_aliased_target ${_module_target} ALIASED_TARGET)
if(_aliased_target)
set(_module_target ${_aliased_target})
endif()
# Include all PluginConfig.cmake files and update the _qt_plugins and QT_PLUGINS property of
# the module. The underscored version is the one we will use going forward to have compatibility
# with INTERFACE libraries. QT_PLUGINS is now deprecated and only kept so that we don't break
# existing projects using it (like CMake itself).
file(GLOB _qt_plugin_config_files
"${CMAKE_CURRENT_LIST_DIR}/${QT_CMAKE_EXPORT_NAMESPACE}*PluginConfig.cmake")
foreach(_config_file ${_qt_plugin_config_files})
string(REGEX REPLACE
"^.*/${QT_CMAKE_EXPORT_NAMESPACE}(.*Plugin)Config.cmake$"
"\\1"
_qt_plugin "${_config_file}")
include("${_config_file}")
if(TARGET "${QT_CMAKE_EXPORT_NAMESPACE}::${_qt_plugin}")
list(APPEND _qt_plugins ${_qt_plugin})
endif()
endforeach()
set_property(TARGET ${_module_target} PROPERTY _qt_plugins ${_qt_plugins})
# TODO: Deprecated. Remove in Qt 7.
set_property(TARGET ${_module_target} PROPERTY QT_PLUGINS ${_qt_plugins})
get_target_property(_have_added_plugins_already ${_module_target} __qt_internal_plugins_added)
if(_have_added_plugins_already)
return()
endif()
foreach(plugin_target ${_qt_plugins})
__qt_internal_plugin_get_plugin_type("${plugin_target}" __has_plugin_type __plugin_type)
if(NOT __has_plugin_type)
continue()
endif()
__qt_internal_plugin_has_class_name("${plugin_target}" __has_class_name)
if(NOT __has_class_name)
continue()
endif()
list(APPEND "QT_ALL_PLUGINS_FOUND_BY_FIND_PACKAGE_${__plugin_type}" "${plugin_target}")
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
# Auto-linkage should be set up only for static plugins.
set(plugin_target_versioned "${QT_CMAKE_EXPORT_NAMESPACE}::${plugin_target}")
get_target_property(type "${plugin_target_versioned}" TYPE)
if(type STREQUAL STATIC_LIBRARY)
CMake: Create and include plugin packages in shared builds Previously QtModulePlugins.cmake files were only created and included in static library Qt builds. Having the targets available in shared library builds would be useful for custom project deployment purposes. One could query the location of the plugins or use various generator expressions referencing their location. Ensure we always generate and include the QtModulePlugins.cmake files regardless of the build type. Allow opting out of including the files by setting QT_SKIP_AUTO_PLUGIN_INCLUSION to ON, just like we allow for Qml plugins with QT_SKIP_AUTO_QML_PLUGIN_INCLUSION. Pick-to: 6.4 Fixes: QTBUG-94066 Change-Id: I69a5dc17762a8e43265578fc33b82b5c4b7a1f5c Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-01 12:45:54 +00:00
__qt_internal_add_static_plugin_linkage("${plugin_target}" "${_module_target}")
__qt_internal_add_static_plugin_import_macro(
"${plugin_target}" ${_module_target} "${target}")
endif()
CMake: Move plugin package inclusion logic into a common function Don't duplicate the logic of plugin package inclusion for each Qt module. Instead move it into QtPublicPluginHelpers.cmake. Pick-to: 6.4 Task-number: QTBUG-94066 Change-Id: I5e1f5176a0e754ed56a792c97865752529462617 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-01 12:29:25 +00:00
endforeach()
set("QT_ALL_PLUGINS_FOUND_BY_FIND_PACKAGE_${__plugin_type}"
"${QT_ALL_PLUGINS_FOUND_BY_FIND_PACKAGE_${__plugin_type}}"
PARENT_SCOPE
)
set_target_properties(${_module_target} PROPERTIES __qt_internal_plugins_added TRUE)
endfunction()
Reference in New Issue Copy Permalink