AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Avoid using prohibited target property names with INTERFACE targets

Browse Source 
CMake 3.19 removed the restrictions on allowable names for properties
on INTERFACE targets. With earlier CMake versions (back to CMake 3.11),
names for custom properties must begin with either a lowercase letter
or an underscore.

In 5807e1ae81 (Add plugins to Qt tools and executables for static
builds, 2021-03-19), the names QT_REPO_PLUGIN_CLASS_NAMES and
QT_REPO_PLUGINS were used, but in some cases, the targets on which they
were being set are INTERFACE targets. Replace these with names that
are supported with CMake 3.11 or later.

Amends 5807e1ae81

Task-number: QTBUG-91915
Pick-to: 6.1
Change-Id: Ife702a1fb339b190d46a8dafb380253219199ba6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This commit is contained in:
Craig Scott 2021-03-31 13:56:51 +11:00
parent 87a4841cb6
commit 256dea0df7
2 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
cmake/QtExecutableHelpers.cmake
View File

@ -197,7 +197,7 @@ function(qt_internal_add_executable name)
endif()
string(MAKE_C_IDENTIFIER "${name}_plugin_imports_${lib}" out_file)
string(APPEND out_file .cpp)
set(class_names "$<GENEX_EVAL:$<TARGET_PROPERTY:${lib},QT_REPO_PLUGIN_CLASS_NAMES>>")
set(class_names "$<GENEX_EVAL:$<TARGET_PROPERTY:${lib},_qt_repo_plugin_class_names>>")
file(GENERATE OUTPUT ${out_file} CONTENT
"// This file is auto-generated. Do not edit.
#include <QtPlugin>
@ -209,7 +209,7 @@ Q_IMPORT_PLUGIN($<JOIN:${class_names},)\nQ_IMPORT_PLUGIN(>)
target_sources(${name} PRIVATE
"$<$<NOT:$<STREQUAL:${class_names},>>:${out_file}>"
)
target_link_libraries(${name} PRIVATE "$<TARGET_PROPERTY:${lib},QT_REPO_PLUGINS>")
target_link_libraries(${name} PRIVATE "$<TARGET_PROPERTY:${lib},_qt_repo_plugins>")
endforeach()
endif()
endfunction()

6
cmake/QtPluginHelpers.cmake
View File

@ -169,8 +169,8 @@ function(qt_internal_add_plugin target)
DEFINITION PROJECT_NAME
)
if(module_project_name STREQUAL PROJECT_NAME)
set_property(TARGET ${qt_module_target} APPEND PROPERTY QT_REPO_PLUGINS "${target}")
set_property(TARGET ${qt_module_target} APPEND PROPERTY QT_REPO_PLUGIN_CLASS_NAMES
set_property(TARGET ${qt_module_target} APPEND PROPERTY _qt_repo_plugins "${target}")
set_property(TARGET ${qt_module_target} APPEND PROPERTY _qt_repo_plugin_class_names
"$<TARGET_PROPERTY:${target},QT_PLUGIN_CLASS_NAME>"
)
endif()
@ -178,7 +178,7 @@ function(qt_internal_add_plugin target)
# TODO: If a repo A provides an internal executable E and a plugin P, with the plugin
# type belonging to a Qt module defined in a different repo, and executable E needs to
# link to plugin P in a static build, currently that won't happen. The executable E
# will link to plugins mentioned in the Qt module's QT_REPO_PLUGINS property, but that
# will link to plugins mentioned in the Qt module's _qt_repo_plugins property, but that
# property will not list P because the Qt module will be an imported target and won't
# have a SOURCE_DIR or PROJECT NAME, so the checks above will not be met.
# Figure out how to handle such a scenario.