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

299 lines
12 KiB
CMake
Raw Normal View History

Add license headers to cmake files CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-05 11:26:52 +00:00
# Copyright (C) 2022 The Qt Company Ltd.
# SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0
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: Make possible building Qt tools without the use of core library Replace BOOTSTRAP option with the single value CORE_LIBRARY argument in qt_internal_add_tool and qt_internal_add_executable functions. The introduced argument now may accept 'Bootstap' and 'None' values. Use 'Bootstap' to link Qt::Boostrap library instead Qt::Core or 'None' to avoid any core library linking. This is useful for tools that need to use the CMake deployment routines, but not require the Qt::Core functionality. Task-number: QTBUG-87480 Change-Id: I64a8b17f16ac5fe43c6b385252dc21def0c88d2c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-05-02 10:48:37 +00:00
# One-value Arguments:
# CORE_LIBRARY
# The argument accepts 'Bootstrap' or 'None' values. If the argument value is set to
# 'Bootstrap' the Qt::Bootstrap library is linked to the executable instead of Qt::Core.
# The 'None' value points that core library is not necessary and avoids linking neither
CMake: Fix typos Found by codespell Pick-to: 6.4 Change-Id: I4907e423b6b345acf82f2d7e0ed62479719d694e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-06-10 14:41:59 +00:00
# Qt::Core or Qt::Bootstrap libraries. Otherwise the Qt::Core library will be publicly
CMake: Make possible building Qt tools without the use of core library Replace BOOTSTRAP option with the single value CORE_LIBRARY argument in qt_internal_add_tool and qt_internal_add_executable functions. The introduced argument now may accept 'Bootstap' and 'None' values. Use 'Bootstap' to link Qt::Boostrap library instead Qt::Core or 'None' to avoid any core library linking. This is useful for tools that need to use the CMake deployment routines, but not require the Qt::Core functionality. Task-number: QTBUG-87480 Change-Id: I64a8b17f16ac5fe43c6b385252dc21def0c88d2c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-05-02 10:48:37 +00:00
# linked to the executable target by default.
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()
Remove unused EXE_FLAGS option from qt_internal_add_executable() The EXE_FLAGS option wasn't being used anywhere in any Qt repo and it had no documentation as to its intended use. Remove it. Pick-to: 6.2 Change-Id: I2f67ec57c1da7dc6eab81d5351361e770d19d7d5 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-17 06:38:07 +00:00
_qt_internal_create_executable(${name})
Add the _qt_internal_android_executable_finalizer wrapper function _qt_internal_android_executable_finalizer wraps Android-related function that are needed to created an Android package. The function is added to the INTERFACE_QT_EXECUTABLE_FINALIZERS property in Qt Core so it's called implicitly for user projects. Pick-to: 6.3 Change-Id: I140f53341691dcfdc6ae2ddea520818cf2834eb6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-02-25 11:33:15 +00:00
if(ANDROID)
_qt_internal_android_executable_finalizer(${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()
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")
fix wrong argument amends 5b136abd21803988f96b9b66c992822efbef97ec Pick-to: 6.2 Change-Id: I8dee597c4ba41ecd07289b724f5e2b52ba705a9f Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-14 09:42:57 +00:00
set_property(TARGET "${name}"
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
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)
wasm: allow apps to override EXPORT_RUNTIME_METHODS Developers can add to Emscripten's EXPORT_RUNTIME_METHODS by defining their own using: QT_WASM_EXTRA_EXPORTED_METHODS Which will add on to Qt's default exported runtime methods of UTF16ToString,stringToUTF16 for cmake: set_target_properties(<target> PROPERTIES QT_WASM_EXTRA_EXPORTED_METHODS "ccall,cwrap") or set(QT_WASM_EXTRA_EXPORTED_METHODS "ccall,cwrap") for qmake: QT_WASM_EXTRA_EXPORTED_METHODS = ccall,cwrap Done-with: Mikolaj Boc Fixes: QTBUG-104882 Pick-to: 6.4 Change-Id: I9678bdb7b077aaa8527057212ea4e161c0be0b60 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 00:07:00 +00:00
qt_internal_wasm_add_finalizers("${name}")
CMake: Make qt6_wasm_add_target_helpers an internal function This function is called by qt_add_executable. There is no need to expose it as public function. Fixes: QTBUG-95172 Change-Id: I85a1d906ecda42458e226db225e47c1d348a72f1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-04 07:44:55 +00:00
_qt_internal_wasm_add_target_helpers("${name}")
wasm: add cmake build support A few configure defines get changed: QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1 To create source maps for debugging. use device-option QT_WASM_SOURCE_MAP=1 Task-number: QTBUG-78647 Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-03 08:29:41 +00:00
endif()
wasm: allow apps to override EXPORT_RUNTIME_METHODS Developers can add to Emscripten's EXPORT_RUNTIME_METHODS by defining their own using: QT_WASM_EXTRA_EXPORTED_METHODS Which will add on to Qt's default exported runtime methods of UTF16ToString,stringToUTF16 for cmake: set_target_properties(<target> PROPERTIES QT_WASM_EXTRA_EXPORTED_METHODS "ccall,cwrap") or set(QT_WASM_EXTRA_EXPORTED_METHODS "ccall,cwrap") for qmake: QT_WASM_EXTRA_EXPORTED_METHODS = ccall,cwrap Done-with: Mikolaj Boc Fixes: QTBUG-104882 Pick-to: 6.4 Change-Id: I9678bdb7b077aaa8527057212ea4e161c0be0b60 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 00:07:00 +00:00
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})
build system: support module local definitions This introduces a new helper function, qt_internal_add_repo_local_defines and makes use of it in qt_internal_add_{module,test,executable,benchmark,plugin}. That function checks whether QT_EXTRA_INTERNAL_TARGET_DEFINES is set. If it is, the defines listed in there will be aded to all targets passed to the functions mentioned above. The intended usage is that QT_EXTRA_INTERNAL_TARGET_DEFINES gets set in the repository local .cmake.conf. This allows e.g. opting in to source incompatible changes in leaf modules (as long as those are guarded by some define). Pick-to: 6.2 6.3 Fixes: QTBUG-101640 Change-Id: I06c3693ee69f46e95a48de724621f0c97e7cc3a8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-03-11 11:41:36 +00:00
qt_internal_add_repo_local_defines(${name})
Fix main() not being visible on Android A recent change refactored the call to qt_internal_add_executable(), but that had the unintended side-effect of changing the symbol visibility from public to hidden. That meant that main() became hidden, so while apps still built successfully, they could not be run. Restore the original symbol visibility to fix this regression. Amends d47278fd09f73ddc34011ab980dafc23aa453e71 Pick-to: 6.2 Change-Id: I27d84ab2b0dd013d5c38dcfe55e88f307c4bc5dd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-20 01:20:46 +00:00
if(ANDROID)
# The above call to qt_set_common_target_properties() sets the symbol
# visibility to hidden, but for Android, we need main() to not be hidden
# because it has to be loadable at runtime using 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 "")
CMake: Make possible building Qt tools without the use of core library Replace BOOTSTRAP option with the single value CORE_LIBRARY argument in qt_internal_add_tool and qt_internal_add_executable functions. The introduced argument now may accept 'Bootstap' and 'None' values. Use 'Bootstap' to link Qt::Boostrap library instead Qt::Core or 'None' to avoid any core library linking. This is useful for tools that need to use the CMake deployment routines, but not require the Qt::Core functionality. Task-number: QTBUG-87480 Change-Id: I64a8b17f16ac5fe43c6b385252dc21def0c88d2c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-05-02 10:48:37 +00:00
if(arg_CORE_LIBRARY STREQUAL "Bootstrap")
list(APPEND extra_libraries ${QT_CMAKE_EXPORT_NAMESPACE}::Bootstrap)
elseif(NOT arg_CORE_LIBRARY STREQUAL "None")
list(APPEND extra_libraries ${QT_CMAKE_EXPORT_NAMESPACE}::Core)
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()
set(private_includes
"${CMAKE_CURRENT_SOURCE_DIR}"
"${CMAKE_CURRENT_BINARY_DIR}"
${arg_INCLUDE_DIRECTORIES}
)
CMake: Deprecate _add_app/executable/test/tool PUBLIC_LIBRARIES option Warn projects not to use it because PUBLIC_LIBRARIES don't make sense for executable targets and it also led to some issues in the internal functions where some of them did not expect to receive PUBLIC_LIBRARIES. To ensure builds don't needlessly break, treat PUBLIC_LIBRARIES values as regular LIBRARIES. In the future we might add an error instead. Using PUBLIC_LIBRARIES in qt_internal_add_app, etc, accidentally worked because the option name and the values following it were parsed as values of the "previous" option, like SOURCES or INCLUDE_DIRECTORIES or LIBRARIES, and when those got passed through to qt_internal_extend_target, things magically worked. We have a lot of projects using PUBLIC_LIBRARIES, mostly due to the way qmake pro files were written and how pro2cmake converted them. We'll have to clean up each repo. Change-Id: I69e09d34afdf98f0d47c08d324643fc986f8131c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 17:56:22 +00:00
if(arg_PUBLIC_LIBRARIES)
message(WARNING
"qt_internal_add_executable's PUBLIC_LIBRARIES option is deprecated, and will be "
"removed in a future Qt version. Use the LIBRARIES option instead.")
endif()
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}
CMake: Deprecate _add_app/executable/test/tool PUBLIC_LIBRARIES option Warn projects not to use it because PUBLIC_LIBRARIES don't make sense for executable targets and it also led to some issues in the internal functions where some of them did not expect to receive PUBLIC_LIBRARIES. To ensure builds don't needlessly break, treat PUBLIC_LIBRARIES values as regular LIBRARIES. In the future we might add an error instead. Using PUBLIC_LIBRARIES in qt_internal_add_app, etc, accidentally worked because the option name and the values following it were parsed as values of the "previous" option, like SOURCES or INCLUDE_DIRECTORIES or LIBRARIES, and when those got passed through to qt_internal_extend_target, things magically worked. We have a lot of projects using PUBLIC_LIBRARIES, mostly due to the way qmake pro files were written and how pro2cmake converted them. We'll have to clean up each repo. Change-Id: I69e09d34afdf98f0d47c08d324643fc986f8131c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 17:56:22 +00:00
LIBRARIES
${arg_LIBRARIES}
${arg_PUBLIC_LIBRARIES}
Qt::PlatformCommonInternal
${extra_libraries}
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
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
CMake: Exclude dSYM INSTALL commands for already excluded tools in debug Debug tools are excluded from the ALL target for debug_and_release builds. However, when using the -separate-debug-info option, the same exclusion wasn't being applied for their dSYM INSTALL commands, resulting in a CMake install error. Pass any additional install args like EXCLUDE_FROM_ALL COMPONENT "ExcludedExecutables" to the installation rules of qt_enable_separate_debug_info and install dSYMs for executables per-config in a multi-config build. All the non-main config executable install rules are optional because the non-main config executables are excluded from ALL. Amends 5b136abd21803988f96b9b66c992822efbef97ec Pick-to: 6.2 Fixes: QTBUG-93999 Change-Id: I95c3ce28215c3ee535551e4b7a5fa9731f8f1c28 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-12 17:27:22 +00:00
if(NOT exclude_from_all AND arg_QT_APP AND QT_FEATURE_debug_and_release)
set(separate_debug_info_executable_arg "QT_EXECUTABLE")
else()
unset(separate_debug_info_executable_arg)
endif()
qt_enable_separate_debug_info(${name} "${arg_INSTALL_DIRECTORY}"
${separate_debug_info_executable_arg}
ADDITIONAL_INSTALL_ARGS ${additional_install_args})
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_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
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
# For static plugins, 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
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(deduped_libs "")
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
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
# 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}")
CMake: Fix auto-linking of static plugins for non-QML in-tree tests Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-20 15:29:48 +00:00
endif()
cmake: 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
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
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
# Unalias the target.
get_target_property(aliased_target ${lib} ALIASED_TARGET)
if(aliased_target)
set(lib ${aliased_target})
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
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
list(APPEND deduped_libs "${lib}")
endforeach()
CMake: Fix auto-linking of static plugins for non-QML in-tree tests Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-20 15:29:48 +00:00
cmake: 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
list(REMOVE_DUPLICATES deduped_libs)
CMake: Fix auto-linking of static plugins for non-QML in-tree tests Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-20 15:29:48 +00:00
cmake: 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
foreach(lib IN LISTS deduped_libs)
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
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
# 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>>")
CMake: Fix auto-linking of static plugins for non-QML in-tree tests Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-20 15:29:48 +00:00
cmake: 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
# 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>>")
CMake: Fix auto-linking of static plugins for non-QML in-tree tests Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-20 15:29:48 +00:00
cmake: 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
# 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: Fix auto-linking of static plugins for non-QML in-tree tests Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-20 15:29:48 +00:00
cmake: 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(out_file_path "${CMAKE_CURRENT_BINARY_DIR}/${out_file}")
CMake: Fix 'Cannot find source file' error with older CMakes Configuring a static qtdeclarative with CMake versions older than 3.18.0 fails at generation phase with CMake Error at cmake/QtExecutableHelpers.cmake:28 (add_executable): Cannot find source file: some_path/some_target_plugin_imports_Gui.cpp Marking the generated file as GENERATED explicitly solves the issue. Pick-to: 6.1 6.2 Change-Id: Ife0eba61a1aab4f988d9fe7e2217d30eb96774a7 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-23 10:16:03 +00:00
cmake: Link static plugins even in shared Qt builds It's perfectly possible to create static plugins in an otherwise shared Qt build, but the logic to import these plugins into applications was assuming a fully static Qt build. We now handle this more granularly. This works for in-source tools and tests as well, which don't go through the same CMake machinery for plugins as user projects do. The only case that does not currently work is in-source examples, as they don't share any of the plugin machinery with neither Qt internal tools/tests or user project, but that's a bigger architectural issue that goes beyond this change. Change-Id: Ie00a97b02ac38ec4affadc447a3bfd0ec7d9c69a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-18 12:20:37 +00:00
file(GENERATE OUTPUT "${out_file_path}" 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(>)
"
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
CONDITION "$<NOT:$<STREQUAL:${class_names},>>"
)
CMake: Fix 'Cannot find source file' error with older CMakes Configuring a static qtdeclarative with CMake versions older than 3.18.0 fails at generation phase with CMake Error at cmake/QtExecutableHelpers.cmake:28 (add_executable): Cannot find source file: some_path/some_target_plugin_imports_Gui.cpp Marking the generated file as GENERATED explicitly solves the issue. Pick-to: 6.1 6.2 Change-Id: Ife0eba61a1aab4f988d9fe7e2217d30eb96774a7 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-23 10:16:03 +00:00
cmake: Link static plugins even in shared Qt builds It's perfectly possible to create static plugins in an otherwise shared Qt build, but the logic to import these plugins into applications was assuming a fully static Qt build. We now handle this more granularly. This works for in-source tools and tests as well, which don't go through the same CMake machinery for plugins as user projects do. The only case that does not currently work is in-source examples, as they don't share any of the plugin machinery with neither Qt internal tools/tests or user project, but that's a bigger architectural issue that goes beyond this change. Change-Id: Ie00a97b02ac38ec4affadc447a3bfd0ec7d9c69a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-18 12:20:37 +00:00
# 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("${out_file_path}" PROPERTIES GENERATED TRUE)
target_sources(${name} PRIVATE
"$<$<NOT:$<STREQUAL:${class_names},>>:${out_file_path}>"
)
target_link_libraries(${name} PRIVATE
"$<TARGET_PROPERTY:${lib},_qt_initial_repo_plugins>"
"$<TARGET_PROPERTY:${lib},${prop_prefix}_plugins>")
endforeach()
CMake: Fix 'Cannot find source file' error with older CMakes Configuring a static qtdeclarative with CMake versions older than 3.18.0 fails at generation phase with CMake Error at cmake/QtExecutableHelpers.cmake:28 (add_executable): Cannot find source file: some_path/some_target_plugin_imports_Gui.cpp Marking the generated file as GENERATED explicitly solves the issue. Pick-to: 6.1 6.2 Change-Id: Ife0eba61a1aab4f988d9fe7e2217d30eb96774a7 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-23 10:16:03 +00:00
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