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

263 lines
11 KiB
CMake
Raw Normal View History

CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
# This function creates a CMake target for a generic console or GUI binary.
# Please consider to use a more specific version target like the one created
# by qt_add_test or qt_add_tool below.
CMake: Rename internal functions to contain qt_internal Offer compatibility wrapper functions until we update all of the Qt repos to use the new names. Task-number: QTBUG-86815 Change-Id: I5826a4116f52a8509db32601ef7c200f9bd331de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2020-09-22 08:02:27 +00:00
function(qt_internal_add_executable name)
CMake: Fix leftover usage of qt_add_executable All usages should be replaced with qt_internal_add_executable instead. This should fix configuration failure of benchmarks and manual tests. Amends e0c62a48b8a826a46a143e57e94b2a0ea73c7cae Task-number: QTBUG-86815 Change-Id: I0791d849998ed9517e32f699d843367949b97cb9 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-07 14:29:38 +00:00
qt_parse_all_arguments(arg "qt_internal_add_executable"
"${__qt_internal_add_executable_optional_args}"
"${__qt_internal_add_executable_single_args}"
"${__qt_internal_add_executable_multi_args}"
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
${ARGN})
if ("x${arg_OUTPUT_DIRECTORY}" STREQUAL "x")
set(arg_OUTPUT_DIRECTORY "${QT_BUILD_DIR}/${INSTALL_BINDIR}")
endif()
get_filename_component(arg_OUTPUT_DIRECTORY "${arg_OUTPUT_DIRECTORY}"
ABSOLUTE BASE_DIR "${QT_BUILD_DIR}")
if ("x${arg_INSTALL_DIRECTORY}" STREQUAL "x")
set(arg_INSTALL_DIRECTORY "${INSTALL_BINDIR}")
endif()
if (ANDROID)
add_library("${name}" MODULE)
qt_android_apply_arch_suffix("${name}")
qt_android_generate_deployment_settings("${name}")
qt_android_add_apk_target("${name}")
else()
add_executable("${name}" ${arg_EXE_FLAGS})
endif()
CMake: Fix installation errors in multi-config build In multi-config builds (which equals the debug-and-release feature) we exclude tools of the non-main configurations from the default build. But we still create installation rules for them. Mark those as optional to avoid "cmake --install" yielding errors if those tools weren't built. Fixes: QTBUG-85411 Change-Id: Ic2d3897d1a1c28a715d9a024ec8606fff00e0315 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-06 20:48:08 +00:00
if(arg_QT_APP AND QT_FEATURE_debug_and_release AND CMAKE_VERSION VERSION_GREATER_EQUAL "3.19.0")
set_property(TARGET "${target}"
PROPERTY EXCLUDE_FROM_ALL "$<NOT:$<CONFIG:${QT_MULTI_CONFIG_FIRST_CONFIG}>>")
endif()
wasm: add cmake build support A few configure defines get changed: QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1 To create source maps for debugging. use device-option QT_WASM_SOURCE_MAP=1 Task-number: QTBUG-78647 Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-03 08:29:41 +00:00
if(WASM)
qt6_wasm_add_target_helpers("${name}")
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
if (arg_VERSION)
if(arg_VERSION MATCHES "[0-9]+\\.[0-9]+\\.[0-9]+\\.[0-9]+")
# nothing to do
elseif(arg_VERSION MATCHES "[0-9]+\\.[0-9]+\\.[0-9]+")
set(arg_VERSION "${arg_VERSION}.0")
elseif(arg_VERSION MATCHES "[0-9]+\\.[0-9]+")
set(arg_VERSION "${arg_VERSION}.0.0")
elseif (arg_VERSION MATCHES "[0-9]+")
set(arg_VERSION "${arg_VERSION}.0.0.0")
else()
message(FATAL_ERROR "Invalid version format")
endif()
endif()
if(arg_DELAY_TARGET_INFO)
# Delay the setting of target info properties if requested. Needed for scope finalization
# of Qt apps.
set_target_properties("${name}" PROPERTIES
QT_DELAYED_TARGET_VERSION "${arg_VERSION}"
QT_DELAYED_TARGET_PRODUCT "${arg_TARGET_PRODUCT}"
QT_DELAYED_TARGET_DESCRIPTION "${arg_TARGET_DESCRIPTION}"
QT_DELAYED_TARGET_COMPANY "${arg_TARGET_COMPANY}"
QT_DELAYED_TARGET_COPYRIGHT "${arg_TARGET_COPYRIGHT}"
)
else()
if("${arg_TARGET_DESCRIPTION}" STREQUAL "")
set(arg_TARGET_DESCRIPTION "Qt ${name}")
endif()
qt_set_target_info_properties(${name} ${ARGN}
TARGET_DESCRIPTION "${arg_TARGET_DESCRIPTION}"
TARGET_VERSION "${arg_VERSION}")
endif()
if (WIN32 AND NOT arg_DELAY_RC)
CMake: Rename some public API functions Some of them have a different (hopefully better) name now. Some are marked as Technical Preview. Some are renamed to be internal. Marking add_qt_gui_executable as TP with the intention to un-TP it after we rename it and change its behavior as discussed in the API review meeting. Additional changes to add_qt_gui_executable and qt6_add_resources have been filed as separate tasks that will be worked on separately. See comments on PS1 for details. Task-number: QTBUG-86827 Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-14 11:20:55 +00:00
_qt_internal_generate_win32_rc_file(${name})
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endif()
qt_set_common_target_properties(${name})
CMake: fix running Android tests Android *.so files need to CXX visibility to default after qt_set_common_target_properties() which was setting it to hidden. Also, pass the correct androidtestrunner arguments for cmake check target Fixes: QTBUG-88228 Change-Id: Ia29cdc9e65153c9669f3ec06f74a46f8fcd8c507 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-12 11:55:25 +00:00
if(ANDROID)
# On our qmake builds we don't compile the executables with
# visibility=hidden. Not having this flag set will cause the
# executable to have main() hidden and can then no longer be loaded
# through dlopen()
set_property(TARGET ${name} PROPERTY C_VISIBILITY_PRESET default)
set_property(TARGET ${name} PROPERTY CXX_VISIBILITY_PRESET default)
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
qt_autogen_tools_initial_setup(${name})
qt_skip_warnings_are_errors_when_repo_unclean("${name}")
set(extra_libraries "")
Use Core library for qmake instead of the Bootstrap library Move the qmake-specific logic of the QLibraryInfo class to qmake internals. 'qconfig.cpp.in' now stores information about the library info entries to keep them consistent between qmake and the Core library. qmake requires specific features enabled in the Core library, so building qmake will be skipped if the features are not enabled. All flags directly related to the qmake have been removed from Core lib. Remove all bootstrap related sections from qmake CMakeLists.txt Task-number: QTBUG-89369 Change-Id: I26de157d3bfd4a5526699296e9d46e1c180b89ae Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2021-01-28 15:06:26 +00:00
if(NOT arg_BOOTSTRAP)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
set(extra_libraries "Qt::Core")
endif()
set(private_includes
"${CMAKE_CURRENT_SOURCE_DIR}"
"${CMAKE_CURRENT_BINARY_DIR}"
${arg_INCLUDE_DIRECTORIES}
)
CMake: Rename internal functions to contain qt_internal Offer compatibility wrapper functions until we update all of the Qt repos to use the new names. Task-number: QTBUG-86815 Change-Id: I5826a4116f52a8509db32601ef7c200f9bd331de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2020-09-22 08:02:27 +00:00
qt_internal_extend_target("${name}"
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
SOURCES ${arg_SOURCES}
INCLUDE_DIRECTORIES ${private_includes}
DEFINES ${arg_DEFINES}
LIBRARIES ${arg_LIBRARIES} Qt::PlatformCommonInternal
PUBLIC_LIBRARIES ${extra_libraries} ${arg_PUBLIC_LIBRARIES}
DBUS_ADAPTOR_SOURCES "${arg_DBUS_ADAPTOR_SOURCES}"
DBUS_ADAPTOR_FLAGS "${arg_DBUS_ADAPTOR_FLAGS}"
DBUS_INTERFACE_SOURCES "${arg_DBUS_INTERFACE_SOURCES}"
DBUS_INTERFACE_FLAGS "${arg_DBUS_INTERFACE_FLAGS}"
COMPILE_OPTIONS ${arg_COMPILE_OPTIONS}
LINK_OPTIONS ${arg_LINK_OPTIONS}
MOC_OPTIONS ${arg_MOC_OPTIONS}
ENABLE_AUTOGEN_TOOLS ${arg_ENABLE_AUTOGEN_TOOLS}
DISABLE_AUTOGEN_TOOLS ${arg_DISABLE_AUTOGEN_TOOLS}
)
set_target_properties("${name}" PROPERTIES
RUNTIME_OUTPUT_DIRECTORY "${arg_OUTPUT_DIRECTORY}"
LIBRARY_OUTPUT_DIRECTORY "${arg_OUTPUT_DIRECTORY}"
WIN32_EXECUTABLE "${arg_GUI}"
MACOSX_BUNDLE "${arg_GUI}"
)
Clear non-relevant CMake compiler flags Add internal function to cleanup compiler flags out of the CMAKE_xxx_FLAGS_xxx variables. Use introduced interface to clear the '/EHsc' flag for the MSVC compiler family. This adjusts the CMake behavior to the qmake one. Change the 'EXCEPTIONS' option handling in helper functions. Add ability to add enabling and disabling exception flags. Previously it was only possible to add disabling exception flags. Fixes: QTBUG-89952 Change-Id: I60d47660a97ae9b5a1d1f4107d352c9e97890144 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-01-21 10:17:58 +00:00
qt_internal_set_exceptions_flags("${name}" ${arg_EXCEPTIONS})
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
# Check if target needs to be excluded from all target. Also affects qt_install.
# Set by qt_exclude_tool_directories_from_default_target.
set(exclude_from_all FALSE)
if(__qt_exclude_tool_directories)
foreach(absolute_dir ${__qt_exclude_tool_directories})
string(FIND "${CMAKE_CURRENT_SOURCE_DIR}" "${absolute_dir}" dir_starting_pos)
if(dir_starting_pos EQUAL 0)
set(exclude_from_all TRUE)
set_target_properties("${name}" PROPERTIES EXCLUDE_FROM_ALL TRUE)
break()
endif()
endforeach()
endif()
if(NOT arg_NO_INSTALL)
set(additional_install_args "")
if(exclude_from_all)
list(APPEND additional_install_args EXCLUDE_FROM_ALL COMPONENT "ExcludedExecutables")
endif()
qt_get_cmake_configurations(cmake_configs)
foreach(cmake_config ${cmake_configs})
qt_get_install_target_default_args(
OUT_VAR install_targets_default_args
CMAKE_CONFIG "${cmake_config}"
ALL_CMAKE_CONFIGS "${cmake_configs}"
RUNTIME "${arg_INSTALL_DIRECTORY}"
LIBRARY "${arg_INSTALL_DIRECTORY}"
BUNDLE "${arg_INSTALL_DIRECTORY}")
CMake: Fix installation errors in multi-config build In multi-config builds (which equals the debug-and-release feature) we exclude tools of the non-main configurations from the default build. But we still create installation rules for them. Mark those as optional to avoid "cmake --install" yielding errors if those tools weren't built. Fixes: QTBUG-85411 Change-Id: Ic2d3897d1a1c28a715d9a024ec8606fff00e0315 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-06 20:48:08 +00:00
# Make installation optional for targets that are not built by default in this config
if(NOT exclude_from_all AND arg_QT_APP AND QT_FEATURE_debug_and_release
AND NOT (cmake_config STREQUAL QT_MULTI_CONFIG_FIRST_CONFIG))
set(install_optional_arg "OPTIONAL")
else()
unset(install_optional_arg)
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
qt_install(TARGETS "${name}"
${additional_install_args} # Needs to be before the DESTINATIONS.
CMake: Fix installation errors in multi-config build In multi-config builds (which equals the debug-and-release feature) we exclude tools of the non-main configurations from the default build. But we still create installation rules for them. Mark those as optional to avoid "cmake --install" yielding errors if those tools weren't built. Fixes: QTBUG-85411 Change-Id: Ic2d3897d1a1c28a715d9a024ec8606fff00e0315 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-06 20:48:08 +00:00
${install_optional_arg}
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
CONFIGURATIONS ${cmake_config}
${install_targets_default_args})
endforeach()
CMake: Install missing debug info for some executable files Although many executable files were generated by qt_internal_add_tool(). Some executable files like designer and androiddeployqt were generated by qt_internal_add_app(). Some executable files like windeployqt were generated by qt_internal_add_executable(). For these executable files, their PDB files won't be installed on MSVC platform, and their separate debug info won't be generated and installed on other platforms. To fix this, qt_enable_separate_debug_info() and qt_internal_install_pdb_files() should also be called in qt_internal_add_executable(). Fixes: QTBUG-88268 Change-Id: Id6a3b5842dba325166e3d696701c82ad942bca74 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-16 05:56:31 +00:00
qt_enable_separate_debug_info(${name} "${arg_INSTALL_DIRECTORY}")
qt_internal_install_pdb_files(${name} "${arg_INSTALL_DIRECTORY}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endif()
CMake: Add convenience custom targets to build Qt plugins Add 3 new convenience custom targets: 'qt_plugins', 'qpa_plugins' and 'qpa_default_plugins'. Additionally, if we detect that an internal executable / test links against Gui, add a dependency on the 'qpa_default_plugins' custom target, so that if a developer configures Qt for the first time and then calls ninja 'tst_foo_check', we ensure the test will launch successfully because the default QPA plugin will also be built. Change-Id: If6dd70844b5effdf8a293f65f8785855cc85b132 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-19 17:34:53 +00:00
# If linking against Gui, make sure to also build the default QPA plugin.
# This makes the experience of an initial Qt configuration to build and run one single
# test / executable nicer.
get_target_property(linked_libs "${name}" LINK_LIBRARIES)
if("Qt::Gui" IN_LIST linked_libs AND TARGET qpa_default_plugins)
add_dependencies("${name}" qpa_default_plugins)
endif()
Add plugins to Qt tools and executables for static builds In static builds, we cannot allow any part of the main build to make a call to find_package(Qt6...) where such a call may load a Qt6*Plugins.cmake file. That would add additional dependencies to the main module targets, setting up a circular dependency in the set of *Config.cmake files which cannot be resolved. This scenario would be triggered by per-repo builds or user projects. But Qt's tools and other executables still need to load some plugins in static builds. Sometimes a platform plugin may be enough, other times we may want all supportable plugins (e.g. Qt Designer). Therefore, add all plugins we can identify as relevant for an executable that is part of the Qt build, but add them directly to the executable without affecting the linking relationships between the main module libraries. Also remove the now unnecessary check for QT_BUILD_PROJECT_NAME in top level builds because there should be no difference between per-repo and top level builds any more (as far as linking static plugins is concerned). Examples that build as part of the main build will still build successfully after this change, but they will not run if they require a platform plugin. Examples need to be moved out to a separate build where they can call find_package(Qt6) without QT_NO_CREATE_TARGETS set to TRUE to be runnable (see QTBUG-90820). Fixes: QTBUG-91915 Pick-to: 6.1 Change-Id: I8088baddb54e394ca111b103313596d6743570ba Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-03-19 09:04:23 +00:00
if(NOT BUILD_SHARED_LIBS)
# For static builds, we need to explicitly link to plugins we want to be
# loaded with the executable. User projects get that automatically, but
# for tools built as part of Qt, we can't use that mechanism because it
# would pollute the targets we export as part of an install and lead to
# circular dependencies. The logic here is a simpler equivalent of the
# more dynamic logic in QtPlugins.cmake.in, but restricted to only
# adding plugins that are provided by the same module as the module
# libraries the executable links to.
set(libs
${arg_LIBRARIES}
${arg_PUBLIC_LIBRARIES}
${extra_libraries}
Qt::PlatformCommonInternal
)
CMake: Fix auto-linking of static plugins for non-QML in-tree tests Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-20 15:29:48 +00:00
set(deduped_libs "")
Add plugins to Qt tools and executables for static builds In static builds, we cannot allow any part of the main build to make a call to find_package(Qt6...) where such a call may load a Qt6*Plugins.cmake file. That would add additional dependencies to the main module targets, setting up a circular dependency in the set of *Config.cmake files which cannot be resolved. This scenario would be triggered by per-repo builds or user projects. But Qt's tools and other executables still need to load some plugins in static builds. Sometimes a platform plugin may be enough, other times we may want all supportable plugins (e.g. Qt Designer). Therefore, add all plugins we can identify as relevant for an executable that is part of the Qt build, but add them directly to the executable without affecting the linking relationships between the main module libraries. Also remove the now unnecessary check for QT_BUILD_PROJECT_NAME in top level builds because there should be no difference between per-repo and top level builds any more (as far as linking static plugins is concerned). Examples that build as part of the main build will still build successfully after this change, but they will not run if they require a platform plugin. Examples need to be moved out to a separate build where they can call find_package(Qt6) without QT_NO_CREATE_TARGETS set to TRUE to be runnable (see QTBUG-90820). Fixes: QTBUG-91915 Pick-to: 6.1 Change-Id: I8088baddb54e394ca111b103313596d6743570ba Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-03-19 09:04:23 +00:00
foreach(lib IN LISTS libs)
if(NOT TARGET "${lib}")
continue()
endif()
CMake: Fix auto-linking of static plugins for non-QML in-tree tests Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-20 15:29:48 +00:00
# Normalize module by stripping any leading "Qt::", because properties are set on the
# versioned target (either Gui when building the module, or Qt6::Gui when it's
# imported).
if(lib MATCHES "Qt::([-_A-Za-z0-9]+)")
set(new_lib "${QT_CMAKE_EXPORT_NAMESPACE}::${CMAKE_MATCH_1}")
if(TARGET "${new_lib}")
set(lib "${new_lib}")
endif()
endif()
# Unalias the target.
get_target_property(aliased_target ${lib} ALIASED_TARGET)
if(aliased_target)
set(lib ${aliased_target})
endif()
list(APPEND deduped_libs "${lib}")
endforeach()
list(REMOVE_DUPLICATES deduped_libs)
foreach(lib IN LISTS deduped_libs)
Add plugins to Qt tools and executables for static builds In static builds, we cannot allow any part of the main build to make a call to find_package(Qt6...) where such a call may load a Qt6*Plugins.cmake file. That would add additional dependencies to the main module targets, setting up a circular dependency in the set of *Config.cmake files which cannot be resolved. This scenario would be triggered by per-repo builds or user projects. But Qt's tools and other executables still need to load some plugins in static builds. Sometimes a platform plugin may be enough, other times we may want all supportable plugins (e.g. Qt Designer). Therefore, add all plugins we can identify as relevant for an executable that is part of the Qt build, but add them directly to the executable without affecting the linking relationships between the main module libraries. Also remove the now unnecessary check for QT_BUILD_PROJECT_NAME in top level builds because there should be no difference between per-repo and top level builds any more (as far as linking static plugins is concerned). Examples that build as part of the main build will still build successfully after this change, but they will not run if they require a platform plugin. Examples need to be moved out to a separate build where they can call find_package(Qt6) without QT_NO_CREATE_TARGETS set to TRUE to be runnable (see QTBUG-90820). Fixes: QTBUG-91915 Pick-to: 6.1 Change-Id: I8088baddb54e394ca111b103313596d6743570ba Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-03-19 09:04:23 +00:00
string(MAKE_C_IDENTIFIER "${name}_plugin_imports_${lib}" out_file)
string(APPEND out_file .cpp)
CMake: Fix auto-linking of static plugins for non-QML in-tree tests Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-20 15:29:48 +00:00
# Initialize plugins that are built in the same repository as the Qt module 'lib'.
set(class_names_regular
"$<GENEX_EVAL:$<TARGET_PROPERTY:${lib},_qt_initial_repo_plugin_class_names>>")
# Initialize plugins that are built in the current Qt repository, but are associated
# with a Qt module from a different repository (qtsvg's QSvgPlugin associated with
# qtbase's QtGui).
string(MAKE_C_IDENTIFIER "${PROJECT_NAME}" current_project_name)
set(prop_prefix "_qt_repo_${current_project_name}")
set(class_names_current_project
"$<GENEX_EVAL:$<TARGET_PROPERTY:${lib},${prop_prefix}_plugin_class_names>>")
# Only add separator if first list is not empty, so we don't trigger the file generation
# when all lists are empty.
set(class_names_separator "$<$<NOT:$<STREQUAL:${class_names_regular},>>:;>" )
set(class_names
"${class_names_regular}${class_names_separator}${class_names_current_project}")
CMake: Explicitly generate static plugin helpers into binary dir Before, it would erroneously look for them in the source directory. Change-Id: I6dcd3ccde3e57dba84639da2cd354c51e8a92459 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-02 13:52:43 +00:00
file(GENERATE OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${out_file} CONTENT
Add plugins to Qt tools and executables for static builds In static builds, we cannot allow any part of the main build to make a call to find_package(Qt6...) where such a call may load a Qt6*Plugins.cmake file. That would add additional dependencies to the main module targets, setting up a circular dependency in the set of *Config.cmake files which cannot be resolved. This scenario would be triggered by per-repo builds or user projects. But Qt's tools and other executables still need to load some plugins in static builds. Sometimes a platform plugin may be enough, other times we may want all supportable plugins (e.g. Qt Designer). Therefore, add all plugins we can identify as relevant for an executable that is part of the Qt build, but add them directly to the executable without affecting the linking relationships between the main module libraries. Also remove the now unnecessary check for QT_BUILD_PROJECT_NAME in top level builds because there should be no difference between per-repo and top level builds any more (as far as linking static plugins is concerned). Examples that build as part of the main build will still build successfully after this change, but they will not run if they require a platform plugin. Examples need to be moved out to a separate build where they can call find_package(Qt6) without QT_NO_CREATE_TARGETS set to TRUE to be runnable (see QTBUG-90820). Fixes: QTBUG-91915 Pick-to: 6.1 Change-Id: I8088baddb54e394ca111b103313596d6743570ba Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-03-19 09:04:23 +00:00
"// This file is auto-generated. Do not edit.
#include <QtPlugin>
Q_IMPORT_PLUGIN($<JOIN:${class_names},)\nQ_IMPORT_PLUGIN(>)
"
CONDITION "$<NOT:$<STREQUAL:${class_names},>>"
)
target_sources(${name} PRIVATE
CMake: Explicitly generate static plugin helpers into binary dir Before, it would erroneously look for them in the source directory. Change-Id: I6dcd3ccde3e57dba84639da2cd354c51e8a92459 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-02 13:52:43 +00:00
"$<$<NOT:$<STREQUAL:${class_names},>>:${CMAKE_CURRENT_BINARY_DIR}/${out_file}>"
Add plugins to Qt tools and executables for static builds In static builds, we cannot allow any part of the main build to make a call to find_package(Qt6...) where such a call may load a Qt6*Plugins.cmake file. That would add additional dependencies to the main module targets, setting up a circular dependency in the set of *Config.cmake files which cannot be resolved. This scenario would be triggered by per-repo builds or user projects. But Qt's tools and other executables still need to load some plugins in static builds. Sometimes a platform plugin may be enough, other times we may want all supportable plugins (e.g. Qt Designer). Therefore, add all plugins we can identify as relevant for an executable that is part of the Qt build, but add them directly to the executable without affecting the linking relationships between the main module libraries. Also remove the now unnecessary check for QT_BUILD_PROJECT_NAME in top level builds because there should be no difference between per-repo and top level builds any more (as far as linking static plugins is concerned). Examples that build as part of the main build will still build successfully after this change, but they will not run if they require a platform plugin. Examples need to be moved out to a separate build where they can call find_package(Qt6) without QT_NO_CREATE_TARGETS set to TRUE to be runnable (see QTBUG-90820). Fixes: QTBUG-91915 Pick-to: 6.1 Change-Id: I8088baddb54e394ca111b103313596d6743570ba Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-03-19 09:04:23 +00:00
)
CMake: Fix auto-linking of static plugins for non-QML in-tree tests Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-20 15:29:48 +00:00
target_link_libraries(${name} PRIVATE
"$<TARGET_PROPERTY:${lib},_qt_initial_repo_plugins>"
"$<TARGET_PROPERTY:${lib},${prop_prefix}_plugins>")
Add plugins to Qt tools and executables for static builds In static builds, we cannot allow any part of the main build to make a call to find_package(Qt6...) where such a call may load a Qt6*Plugins.cmake file. That would add additional dependencies to the main module targets, setting up a circular dependency in the set of *Config.cmake files which cannot be resolved. This scenario would be triggered by per-repo builds or user projects. But Qt's tools and other executables still need to load some plugins in static builds. Sometimes a platform plugin may be enough, other times we may want all supportable plugins (e.g. Qt Designer). Therefore, add all plugins we can identify as relevant for an executable that is part of the Qt build, but add them directly to the executable without affecting the linking relationships between the main module libraries. Also remove the now unnecessary check for QT_BUILD_PROJECT_NAME in top level builds because there should be no difference between per-repo and top level builds any more (as far as linking static plugins is concerned). Examples that build as part of the main build will still build successfully after this change, but they will not run if they require a platform plugin. Examples need to be moved out to a separate build where they can call find_package(Qt6) without QT_NO_CREATE_TARGETS set to TRUE to be runnable (see QTBUG-90820). Fixes: QTBUG-91915 Pick-to: 6.1 Change-Id: I8088baddb54e394ca111b103313596d6743570ba Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-03-19 09:04:23 +00:00
endforeach()
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endfunction()
Reference in New Issue Copy Permalink