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

493 lines
19 KiB
CMake
Raw Normal View History

Add license headers to cmake files CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-05 11:26:52 +00:00
# Copyright (C) 2022 The Qt Company Ltd.
Change the license of all CMakeLists.txt and *.cmake files to BSD Task-number: QTBUG-105718 Change-Id: I5d3ef70a31235868b9be6cb479b7621bf2a8ba39 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-08-19 13:21:34 +00:00
# SPDX-License-Identifier: BSD-3-Clause
Add license headers to cmake files CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-05 11:26:52 +00:00
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)
Retire the qt_parse_all_arguments This replaces the qt_parse_all_arguments macro with the built-in `cmake_parse_arguments(PARSE_ARGV`. In addition, a new function, _qt_internal_validate_all_args_are_parsed, can be used to check whether any _UNPARSED_ARGUMENTS have been passed to the function. Fixes: QTBUG-99238 Change-Id: I8cee83dc92dc6acdaaf747ea6ff9084c11dc649b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-11 14:36:18 +00:00
cmake_parse_arguments(PARSE_ARGV 1 arg
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_internal_add_executable_optional_args}"
"${__qt_internal_add_executable_single_args}"
Retire the qt_parse_all_arguments This replaces the qt_parse_all_arguments macro with the built-in `cmake_parse_arguments(PARSE_ARGV`. In addition, a new function, _qt_internal_validate_all_args_are_parsed, can be used to check whether any _UNPARSED_ARGUMENTS have been passed to the function. Fixes: QTBUG-99238 Change-Id: I8cee83dc92dc6acdaaf747ea6ff9084c11dc649b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-11 14:36:18 +00:00
"${__qt_internal_add_executable_multi_args}")
_qt_internal_validate_all_args_are_parsed(arg)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
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()
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()
Add some utilities for UNITY_BUILD - The following commands accepts NO_UNITY_BUILD, and NO_UNITY_BUILD_SOURCES arguments to opt out of the unity build, and to exclude some source files from unity build, respectively. - qt_internal_add_executable - qt_internal_add_module - qt_internal_add_plugin - qt_internal_add_tool - qt_internal_extend_target - qt_internal_add_common_qt_library_helper - qt_internal_add_cmake_library - qt_internal_add_simd_part - Unity build is disabled by default in these: - qt_internal_add_test - qt_internal_add_test_helper - qt_internal_add_benchmark - qt_internal_add_3rdparty_library - qt_update_ignore_pch_source also excludes the files from unity_build Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: I5d0e7df633738310a015142a6c73fbb78b6c3467 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-31 13:05:16 +00:00
if(arg_NO_UNITY_BUILD)
Fix an issue with passing NO_UNITY_BUILD_SOURCES Amend 31518f1a4e3c4a7c77ae2e008e903a849ba75dd6 Amend 360293623094a31586981206e59c92aa6235163d Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: Ibb2fd881c02b6496f06b8b623fa6009358755a26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-15 09:46:22 +00:00
set(arg_NO_UNITY_BUILD "NO_UNITY_BUILD")
Add some utilities for UNITY_BUILD - The following commands accepts NO_UNITY_BUILD, and NO_UNITY_BUILD_SOURCES arguments to opt out of the unity build, and to exclude some source files from unity build, respectively. - qt_internal_add_executable - qt_internal_add_module - qt_internal_add_plugin - qt_internal_add_tool - qt_internal_extend_target - qt_internal_add_common_qt_library_helper - qt_internal_add_cmake_library - qt_internal_add_simd_part - Unity build is disabled by default in these: - qt_internal_add_test - qt_internal_add_test_helper - qt_internal_add_benchmark - qt_internal_add_3rdparty_library - qt_update_ignore_pch_source also excludes the files from unity_build Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: I5d0e7df633738310a015142a6c73fbb78b6c3467 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-31 13:05:16 +00:00
else()
set(arg_NO_UNITY_BUILD "")
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}"
Improvement to NO_UNITY_BUILD_SOURCES, and fix related bugs The source of the problem was in `qt_set_target_info_properties` which was not able to process the NO_UNITY_BUILD_SOURCES, and therefore leaking it into the `TARGET_COPYRIGHT`, ie., the last argument. So, I decided to pass Unity Build arguments before them, and closer to SOURCES, which is nicer to read, and avoid similar situation. And I reverted the work around in the amend commit, and passing the arguments normally. This happens because we pass an unfiltered ${ARGN} from qt_internal_add_executable to qt_set_target_info_properties and that the current change is merely a workaround that ensures they get circumstantially filtered out, because the NO_UNITY_BUILD_SOURCES option appears before any of the first TARGET_ props. Amend cd12c1f33281452d478bb94744d76bead5c7363a Task-number: QTBUG-99238 Task-number: QTBUG-109394 Pick-to: 6.5 Change-Id: Idb37937cf53e708425402c90f55bda8816e27f29 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-29 09:38:30 +00:00
${arg_NO_UNITY_BUILD}
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}
Improvement to NO_UNITY_BUILD_SOURCES, and fix related bugs The source of the problem was in `qt_set_target_info_properties` which was not able to process the NO_UNITY_BUILD_SOURCES, and therefore leaking it into the `TARGET_COPYRIGHT`, ie., the last argument. So, I decided to pass Unity Build arguments before them, and closer to SOURCES, which is nicer to read, and avoid similar situation. And I reverted the work around in the amend commit, and passing the arguments normally. This happens because we pass an unfiltered ${ARGN} from qt_internal_add_executable to qt_set_target_info_properties and that the current change is merely a workaround that ensures they get circumstantially filtered out, because the NO_UNITY_BUILD_SOURCES option appears before any of the first TARGET_ props. Amend cd12c1f33281452d478bb94744d76bead5c7363a Task-number: QTBUG-99238 Task-number: QTBUG-109394 Pick-to: 6.5 Change-Id: Idb37937cf53e708425402c90f55bda8816e27f29 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-29 09:38:30 +00:00
NO_UNITY_BUILD_SOURCES ${arg_NO_UNITY_BUILD_SOURCES}
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
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}
Remove the extra quote, now that we use cmake_parse_arguments(PARSE_ARGV The extra quote enforces the arguments to be string, and stops the COMMAND_EXPAND_LISTS within QtDbusHelpers.cmake::qt_create_qdbusxml2cpp_command from expanding it as a list. Fixes: QTBUG-110459 Fixes: QTBUG-110450 Task-number: QTBUG-99238 Change-Id: Ifddd6570c7bf8f2d1757f275d9445ce2924a93f1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-01-23 12:52:20 +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}
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
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
Set NO_EXCEPTIONS on executables on wasm This reflects the true state of exceptions on WASM, which are always disabled (DISABLE_EXCEPTION_CATCHING is always set with 1). Change-Id: I7b681846159caf61f291f78a7b4ddf5260dc341f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-09-14 17:36:01 +00:00
if(WASM)
# WASM unconditionally sets DISABLE_EXCEPTION_CATCHING=1
qt_internal_set_exceptions_flags("${name}" NO_EXCEPTIONS)
else()
qt_internal_set_exceptions_flags("${name}" ${arg_EXCEPTIONS})
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
Plug the WASM batched test runner into the build system The new batched test runner is now used for running the tests instead of the wasm shell, which runs for single test cases. Change-Id: I7b7e6dd7993ba7937124c5843356b6891301b893 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-24 07:33:26 +00:00
if(WASM)
qt_internal_wasm_add_finalizers("${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
# 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()
Add function to add and compile executables at configure time qt_internal_add_configure_time_executable compiles the executable at configure time and exposes it to the CMake source tree. This is useful when need to run a small C++ program at configure time. Task-number: QTBUG-87480 Change-Id: I031efe797c8afa0721d75b46d4f36f67276bf46e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-03 15:46:15 +00:00
# This function compiles the target at configure time the very first time and creates the custom
# ${target}_build that re-runs compilation at build time if necessary. The resulting executable is
# imported under the provided target name. This function should only be used to compile tiny
# executables with system dependencies only.
# One-value Arguments:
# CMAKELISTS_TEMPLATE
# The CMakeLists.txt templated that is used to configure the project
# for an executable. By default the predefined template from the Qt installation is used.
# INSTALL_DIRECTORY
# installation directory of the executable. Ignored if NO_INSTALL is set.
# OUTPUT_NAME
# the output name of an executable
# CONFIG
# the name of configuration that tool needs to be build with.
# Multi-value Arguments:
# PACKAGES
# list of system packages are required to successfully build the project.
# INCLUDES
# list of include directories are required to successfully build the project.
# DEFINES
# list of definitions are required to successfully build the project.
# COMPILE_OPTIONS
# list of compiler options are required to successfully build the project.
# LINK_OPTIONS
# list of linker options are required to successfully build the project.
# SOURCES
# list of project sources.
# CMAKE_FLAGS
# specify flags of the form -DVAR:TYPE=VALUE to be passed to the cmake command-line used to
# drive the test build.
# Options:
# WIN32
# reflects the corresponding add_executable argument.
# MACOSX_BUNDLE
# reflects the corresponding add_executable argument.
# NO_INSTALL
# avoids installing the tool.
function(qt_internal_add_configure_time_executable target)
set(one_value_args
CMAKELISTS_TEMPLATE
INSTALL_DIRECTORY
OUTPUT_NAME
CONFIG
)
set(multi_value_args
PACKAGES
INCLUDES
DEFINES
COMPILE_OPTIONS
LINK_OPTIONS
SOURCES
CMAKE_FLAGS
)
set(option_args WIN32 MACOSX_BUNDLE NO_INSTALL)
Use PARSE_ARGV signature to process arguments instead of escaping Use PARSE_ARGV signature of the cmake_parse_arguments function to avoid escaping of semicolons when passing arguments to the qt_internal_add_configure_time_tool and qt_internal_add_configure_time_executable function. Amends ac74b60c9c1101288eb2c558420ba69f675a2ee2 Task-number: QTBUG-87480 Change-Id: I343abbd75107e56aaccab6e388db8dbda0525af3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-09-15 09:56:42 +00:00
cmake_parse_arguments(PARSE_ARGV 1 arg
"${option_args}" "${one_value_args}" "${multi_value_args}")
Add function to add and compile executables at configure time qt_internal_add_configure_time_executable compiles the executable at configure time and exposes it to the CMake source tree. This is useful when need to run a small C++ program at configure time. Task-number: QTBUG-87480 Change-Id: I031efe797c8afa0721d75b46d4f36f67276bf46e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-03 15:46:15 +00:00
set(target_binary_dir "${CMAKE_CURRENT_BINARY_DIR}/configure_time_bins")
if(arg_CONFIG)
set(CMAKE_TRY_COMPILE_CONFIGURATION "${arg_CONFIG}")
endif()
get_cmake_property(is_multi_config GENERATOR_IS_MULTI_CONFIG)
if(is_multi_config AND CMAKE_TRY_COMPILE_CONFIGURATION)
set(configuration_path "${CMAKE_TRY_COMPILE_CONFIGURATION}/")
set(config_build_arg "--config" "${CMAKE_TRY_COMPILE_CONFIGURATION}")
endif()
set(configure_time_target "${target}")
if(arg_OUTPUT_NAME)
set(configure_time_target "${arg_OUTPUT_NAME}")
endif()
set(target_binary "${configure_time_target}${CMAKE_EXECUTABLE_SUFFIX}")
Change the RUNTIME_OUTPUT_DIRECTORY for configure-time executables Set the RUNTIME_OUTPUT_DIRECTORY for configure-time executables so executable will be located inside the QT_BUILD_DIR. This allows to re-build syncqt and make sure ithat ts binary is replaced and located in the libexec directory. Comment on how to rebuild syncqt. Configure-time tools reserve the original tool name for the imported executable. To re-build syncqt use 'syncqt_build' target. Task-number: QTBUG-109792 Change-Id: Id7d912b1d75d18d82cb2a69fbd62b89440120d78 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2023-01-03 16:54:18 +00:00
set(install_dir "${INSTALL_BINDIR}")
if(arg_INSTALL_DIRECTORY)
set(install_dir "${arg_INSTALL_DIRECTORY}")
endif()
set(output_directory "${QT_BUILD_DIR}/${install_dir}")
Add function to add and compile executables at configure time qt_internal_add_configure_time_executable compiles the executable at configure time and exposes it to the CMake source tree. This is useful when need to run a small C++ program at configure time. Task-number: QTBUG-87480 Change-Id: I031efe797c8afa0721d75b46d4f36f67276bf46e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-03 15:46:15 +00:00
set(target_binary_path
Change the RUNTIME_OUTPUT_DIRECTORY for configure-time executables Set the RUNTIME_OUTPUT_DIRECTORY for configure-time executables so executable will be located inside the QT_BUILD_DIR. This allows to re-build syncqt and make sure ithat ts binary is replaced and located in the libexec directory. Comment on how to rebuild syncqt. Configure-time tools reserve the original tool name for the imported executable. To re-build syncqt use 'syncqt_build' target. Task-number: QTBUG-109792 Change-Id: Id7d912b1d75d18d82cb2a69fbd62b89440120d78 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2023-01-03 16:54:18 +00:00
"${output_directory}/${configuration_path}${target_binary}")
Add function to add and compile executables at configure time qt_internal_add_configure_time_executable compiles the executable at configure time and exposes it to the CMake source tree. This is useful when need to run a small C++ program at configure time. Task-number: QTBUG-87480 Change-Id: I031efe797c8afa0721d75b46d4f36f67276bf46e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-03 15:46:15 +00:00
get_filename_component(target_binary_path "${target_binary_path}" ABSOLUTE)
if(NOT DEFINED arg_SOURCES)
message(FATAL_ERROR "No SOURCES given to target: ${target}")
endif()
set(sources "${arg_SOURCES}")
# Timestamp file is required because CMake ignores 'add_custom_command' if we use only the
# binary file as the OUTPUT.
Change the RUNTIME_OUTPUT_DIRECTORY for configure-time executables Set the RUNTIME_OUTPUT_DIRECTORY for configure-time executables so executable will be located inside the QT_BUILD_DIR. This allows to re-build syncqt and make sure ithat ts binary is replaced and located in the libexec directory. Comment on how to rebuild syncqt. Configure-time tools reserve the original tool name for the imported executable. To re-build syncqt use 'syncqt_build' target. Task-number: QTBUG-109792 Change-Id: Id7d912b1d75d18d82cb2a69fbd62b89440120d78 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2023-01-03 16:54:18 +00:00
set(timestamp_file "${target_binary_dir}/${target_binary}_timestamp")
Add function to add and compile executables at configure time qt_internal_add_configure_time_executable compiles the executable at configure time and exposes it to the CMake source tree. This is useful when need to run a small C++ program at configure time. Task-number: QTBUG-87480 Change-Id: I031efe797c8afa0721d75b46d4f36f67276bf46e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-03 15:46:15 +00:00
add_custom_command(OUTPUT "${target_binary_path}" "${timestamp_file}"
COMMAND
${CMAKE_COMMAND} --build "${target_binary_dir}" ${config_build_arg}
COMMAND
${CMAKE_COMMAND} -E touch "${timestamp_file}"
DEPENDS
${sources}
COMMENT
"Compiling ${target}"
VERBATIM
)
add_custom_target(${target}_build ALL
DEPENDS
"${target_binary_path}"
"${timestamp_file}"
)
Check if configure-time executable need to be recompiled Respect source files that belong to configure-time executable when reconfiguring Qt. Amends: ac74b60c9c1101288eb2c558420ba69f675a2ee2 Task-number: QTBUG-87480 Change-Id: I7e42ffe8b1b79686c0cf93a02101f0b8e6be0bea Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-09-27 17:14:14 +00:00
set(should_build_at_configure_time TRUE)
if(EXISTS "${target_binary_path}")
set(last_ts 0)
foreach(source IN LISTS sources)
file(TIMESTAMP "${source}" ts "%s")
if(${ts} GREATER ${last_ts})
set(last_ts ${ts})
endif()
endforeach()
file(TIMESTAMP "${target_binary_path}" ts "%s")
if(${ts} GREATER_EQUAL ${last_ts})
set(should_build_at_configure_time FALSE)
endif()
endif()
if(should_build_at_configure_time)
Add function to add and compile executables at configure time qt_internal_add_configure_time_executable compiles the executable at configure time and exposes it to the CMake source tree. This is useful when need to run a small C++ program at configure time. Task-number: QTBUG-87480 Change-Id: I031efe797c8afa0721d75b46d4f36f67276bf46e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-03 15:46:15 +00:00
foreach(arg IN LISTS multi_value_args)
string(TOLOWER "${arg}" template_arg_name)
set(${template_arg_name} "")
if(DEFINED arg_${arg})
set(${template_arg_name} "${arg_${arg}}")
endif()
endforeach()
foreach(arg IN LISTS option_args)
string(TOLOWER "${arg}" template_arg_name)
set(${template_arg_name} "")
if(arg_${arg})
set(${template_arg_name} "${arg}")
endif()
endforeach()
file(MAKE_DIRECTORY "${target_binary_dir}")
set(template "${QT_CMAKE_DIR}/QtConfigureTimeExecutableCMakeLists.txt.in")
if(DEFINED arg_CMAKELISTS_TEMPLATE)
set(template "${arg_CMAKELISTS_TEMPLATE}")
endif()
set(cmake_flags_arg)
if(arg_CMAKE_FLAGS)
Replace the syncqt.pl script with syncqt tool syncqt.pl adds an extra dependency on perl when building Qt. Modern C++ provides the convenient cross-platform way to access a filesystem and to use regular expressions, so we may replace the perl script with C++ application. The syncqt executable is built at configure time and installed as QtCore tool. It's running at configure time to deliver the required header files for IDE to build a consistent code model and at the build time to keep tracking changes in header files and generate the missing aliases without reconfiguring. 'syncqt' only parses header files from a CMake build tree, so the resulting Qt installation only contains interfacing headers that belong to the platform that Qt is built for. 'sync.profile' files are not used as the 'source of truth' for sync qt procedure anymore, all the necessary information is taken from either CMake files at configure time or from the module header files while parsing them. syncqt.pl is still in place since it's required as fallback solution for a smooth transition to the new syncqt implementation for all qt repositories. This patchset only enables the C++ based syncqt for 'qtbase' repository. From the performance perspective C++ version works faster then perl script, also the configure time is reduced significally on subsequent reconfigurations - up x2 times faster when re-configuring repository, but it also takes time to compile the tool itself the first time. Numbers for qtbase: syncqt.pl syncqt.cpp initial: 0m16,035s 0m20,413s reconfig: 0m6,819s 0m3,725s The syncing procedure can be run separately for each module using <ModuleName>_sync_headers targets. The 'sync_headers' target can be used to sync all the modules at once. Task-number: QTBUG-87480 Task-number: QTBUG-103196 Change-Id: I8c938bcaf88a8713b39bbfd66d9e7ef12b2c3523 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-15 16:29:41 +00:00
set(cmake_flags_arg CMAKE_FLAGS "${arg_CMAKE_FLAGS}")
Add function to add and compile executables at configure time qt_internal_add_configure_time_executable compiles the executable at configure time and exposes it to the CMake source tree. This is useful when need to run a small C++ program at configure time. Task-number: QTBUG-87480 Change-Id: I031efe797c8afa0721d75b46d4f36f67276bf46e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-03 15:46:15 +00:00
endif()
configure_file("${template}" "${target_binary_dir}/CMakeLists.txt" @ONLY)
try_compile(result
"${target_binary_dir}"
"${target_binary_dir}"
${target}
${cmake_flags_arg}
OUTPUT_VARIABLE try_compile_output
)
if(NOT result)
message(FATAL_ERROR "Unable to build ${target}: ${try_compile_output}")
endif()
endif()
add_executable(${target} IMPORTED GLOBAL)
add_executable(${QT_CMAKE_EXPORT_NAMESPACE}::${target} ALIAS ${target})
set_target_properties(${target} PROPERTIES
_qt_internal_configure_time_target TRUE
IMPORTED_LOCATION "${target_binary_path}")
if(NOT arg_NO_INSTALL)
set_target_properties(${target} PROPERTIES
_qt_internal_configure_time_target_install_location
"${install_dir}/${target_binary}"
)
qt_path_join(target_install_dir ${QT_INSTALL_DIR} ${install_dir})
Change the RUNTIME_OUTPUT_DIRECTORY for configure-time executables Set the RUNTIME_OUTPUT_DIRECTORY for configure-time executables so executable will be located inside the QT_BUILD_DIR. This allows to re-build syncqt and make sure ithat ts binary is replaced and located in the libexec directory. Comment on how to rebuild syncqt. Configure-time tools reserve the original tool name for the imported executable. To re-build syncqt use 'syncqt_build' target. Task-number: QTBUG-109792 Change-Id: Id7d912b1d75d18d82cb2a69fbd62b89440120d78 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2023-01-03 16:54:18 +00:00
qt_install(PROGRAMS "${target_binary_path}" DESTINATION "${target_install_dir}")
Add function to add and compile executables at configure time qt_internal_add_configure_time_executable compiles the executable at configure time and exposes it to the CMake source tree. This is useful when need to run a small C++ program at configure time. Task-number: QTBUG-87480 Change-Id: I031efe797c8afa0721d75b46d4f36f67276bf46e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-03 15:46:15 +00:00
endif()
endfunction()
Reference in New Issue Copy Permalink