qiurui
/
qtbase
mirror of https://github.com/qt/qtbase.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
qtbase/cmake/QtTargetHelpers.cmake

1873 lines
78 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 can be used to add sources/libraries/etc. to the specified CMake target
# if the provided CONDITION evaluates to true.
Cleanup qt_internal_extend_target function Extract function arguments to the corresponding variables and use variables when parsing arguments. Remove whitespace between if keyword and parentheses. Adjust size of code lines. Document function-specific arguments. Change-Id: I1c77fbf268618a844726683768575aff05894c70 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 12:38:23 +00:00
# One-value Arguments:
# PRECOMPILED_HEADER
# Name of the precompiled header that is used for the target.
CMake: fix documentation of EXTRA_ELF_LINKER_SCRIPT_CONTENT EXTRA_ELF_LINKER_SCRIPT_CONTENT was implemented as single-argument, but documented as multi-argument keyword. This patch aligns docs to implementation Pick-to: 6.10 Change-Id: Ibf7921e7dfedb11bbee25fff9f3d8de702a717a7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-08-12 05:56:45 +00:00
# EXTRA_ELF_LINKER_SCRIPT_CONTENT
# Extra content that should be appended to a target linker script. Applicable for ld only.
CMake: support reduced relocations for namespaced Qt The dynlist files passed to the linker have hardcoded function names that do not take namespacing into account. We therefore generate the dynlist files at configure time from the qt namespace. Task-number: QTBUG-138543 Pick-to: 6.10 Change-Id: Ib3521b83942548cb09c11687e1701c2308f9d148 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-08-07 02:12:26 +00:00
# ELF_LINKER_DYNAMIC_LIST
# Pass --dynamic-list to the linker.
Cleanup qt_internal_extend_target function Extract function arguments to the corresponding variables and use variables when parsing arguments. Remove whitespace between if keyword and parentheses. Adjust size of code lines. Document function-specific arguments. Change-Id: I1c77fbf268618a844726683768575aff05894c70 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 12:38:23 +00:00
# Multi-value Arguments:
# CONDITION
# The condition under which the target will be extended.
Add CONDITION_INDEPENDENT_SOURCES argument to qt_internal_extend_target The argument allows to ignore the condition for source files if they are used in the Qt code without corresponding guards. The header files of this kind usually have internal guards, that suppress the error at the location where they are used, so AUTOGEN is skipped for these header files to suppress the warnings from CMake. If file belongs to a module, it will display AUTHOR_WARNING which should urge Qt maintainers to guard the use of the source file properly. Task-number: QTBUG-103196 Change-Id: I7b4c12031a5d19ff15868d4782c0d396ef7aed8c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2022-11-03 15:38:51 +00:00
# CONDITION_INDEPENDENT_SOURCES
# Source files that should be added to the target unconditionally. Note that if target is Qt
# module, these files will raise a warning at configure time if the condition is not met.
Cleanup qt_internal_extend_target function Extract function arguments to the corresponding variables and use variables when parsing arguments. Remove whitespace between if keyword and parentheses. Adjust size of code lines. Document function-specific arguments. Change-Id: I1c77fbf268618a844726683768575aff05894c70 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 12:38:23 +00:00
# COMPILE_FLAGS
# Custom compilation flags.
CMake: prefix elf to linker script keywords/properties The linker script properties/keywords are only used for elf targets, so we rename them to make the code more expressive. Pick-to: 6.10 Change-Id: I94cf843c78bb8d9650807e3b9584b1b983c3cf47 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-08-12 05:50:55 +00:00
# EXTRA_ELF_LINKER_SCRIPT_EXPORTS
Remove Qt_6_PRIVATE_API ELF version from a symbol used by QFuture::then() QFuture::then() uses QtPrivate::Continuation::create(), which in turn uses private API from an inline function: f->d.setContinuation(ContinuationWrapper(std::move(continuation)), fi.d); f->d is QFutureInterfaceBase (a public class), but its setContinuation() takes QFutureInterfaceBasePrivate by pointer. Our ELF versioning scripts mark everything that uses that class as private, resulting in: 4806: 0000000000287d70 365 FUNC GLOBAL PROTECTED 16 _ZN20QFutureInterfaceBase15setContinuationESt8functionIFvRKS_EEP27QFutureInterfaceBasePrivate@@Qt_6_PRIVATE_API This commit adds an exception for this symbol, causing it to go back to the regular "Qt_6" ELF version: 5629: 00000000003d6a16 366 FUNC GLOBAL PROTECTED 16 _ZN20QFutureInterfaceBase15setContinuationESt8functionIFvRKS_EEP27QFutureInterfaceBasePrivate@@Qt_6 This solution can probably be cleaned up a bit by moving the marker into the header files parsed by syncqt, so they follow code motion without having to remember to update the CMakeLists.txt. That requires some surgery with syncqt, so not suitable for cherry-picking. As a drive-by, fix the target_type check for the _qt_extra_linker_script_content genex property Fixes: QTBUG-117514 Pick-to: 6.6 Change-Id: I85599ea5ca7a4b79a8bbfffd178b92e73dbe11de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-10-06 16:53:26 +00:00
# Extra content that should be added to export section of the linker script.
Cleanup qt_internal_extend_target function Extract function arguments to the corresponding variables and use variables when parsing arguments. Remove whitespace between if keyword and parentheses. Adjust size of code lines. Document function-specific arguments. Change-Id: I1c77fbf268618a844726683768575aff05894c70 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 12:38:23 +00:00
# NO_PCH_SOURCES
cmake: improve documentation of NO_PCH_SOURCES Add the reference to unity builds in the documentation of NO_PCH_SOURCES to fully describe the semantics. Change-Id: Icfd3ee401efa154da4b8ed9a307d29f2605d948a Reviewed-by: Marc Mutz <marc.mutz@qt.io>
2024-02-07 02:18:54 +00:00
# Exclude the specified source files from PRECOMPILE_HEADERS and UNITY_BUILD builds.
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_extend_target target)
Implement the batch_tests feature An approach of test batching (joining multiple tests into a single binary) has been taken, due to long linking times/binary size on certain platforms, including WASM. This change adds a new feature 'batch_test_support' in Qt testlib. Based on the value of the feature, test batching may become enabled with the -batch-tests switch. Batching works for every target added via qt_internal_add_test. When first such target is being processed, a new combined target for all of the future test sources is created under the name of 'test_batch'. CMake attempts to merge the parameters of each of the tests, and some basic checks are run for parameter differences that are impossible to reconcile. On the C++ level, convenience macros instantiating the tests are redefined when batch_tests is on. The new, changed behavior triggered by the changes in the macros registers the tests in a central test registry, where they are available for execution based solely on their test name. The test name is interoperable with the names CMake is aware of, so CTest is able to run the tests one by one in the combined binary. Task-number: QTBUG-105273 Change-Id: I2b6071d58be16979bd967eab2d405249f5a4e658 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
2022-07-12 16:15:24 +00:00
if(NOT TARGET "${target}")
Make qt cmake functions react properly to batch dummy targets Stub targets introduced in 65b7aacb make the old batch target detecting measure in qt_internal_extend_target, qt_internal_undefine_global_definition, qt_internal_add_resource obsolete, since now the targets actually exist in the build system. Unconditionally fail if the target does not exist and if it does, query for its inclusion in the batch Change-Id: I1cd1d8cc7fbf4bdbd2289a1b38ecbea1e93a06c8 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2023-01-02 18:19:44 +00:00
message(FATAL_ERROR "${target} is not a target.")
endif()
Skip tests outside of qtbase on batching+superbuild The batcher does not currently work properly with non-qtbase submodules. Disable them temporarily so that at least the tests in qtbase are batched. Do this from qtbase so that changes to each and every submodule are not necessary. Also, maintain a list of tests that were thus skipped. On any qt cmake internal function call that refers to such a target, identify the target as skipped and make the call a no-op. Fixes: QTBUG-109785 Change-Id: Ib0aa5d39eee8315ffd4ac62f6d1f44fe9bbf7a2f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-03 13:42:33 +00:00
qt_internal_is_skipped_test(skipped ${target})
if(skipped)
return()
endif()
Make qt cmake functions react properly to batch dummy targets Stub targets introduced in 65b7aacb make the old batch target detecting measure in qt_internal_extend_target, qt_internal_undefine_global_definition, qt_internal_add_resource obsolete, since now the targets actually exist in the build system. Unconditionally fail if the target does not exist and if it does, query for its inclusion in the batch Change-Id: I1cd1d8cc7fbf4bdbd2289a1b38ecbea1e93a06c8 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2023-01-02 18:19:44 +00:00
qt_internal_is_in_test_batch(in_batch ${target})
if(in_batch)
Make qt_internal_test_batch_target_name publicly available The batch test target name is a useful thing to obtain in various target-generating scripts. Change-Id: I9605cf860fe1485e48108eba7e93f9064209d8fb Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-24 07:28:37 +00:00
_qt_internal_test_batch_target_name(target)
Implement the batch_tests feature An approach of test batching (joining multiple tests into a single binary) has been taken, due to long linking times/binary size on certain platforms, including WASM. This change adds a new feature 'batch_test_support' in Qt testlib. Based on the value of the feature, test batching may become enabled with the -batch-tests switch. Batching works for every target added via qt_internal_add_test. When first such target is being processed, a new combined target for all of the future test sources is created under the name of 'test_batch'. CMake attempts to merge the parameters of each of the tests, and some basic checks are run for parameter differences that are impossible to reconcile. On the C++ level, convenience macros instantiating the tests are redefined when batch_tests is on. The new, changed behavior triggered by the changes in the macros registers the tests in a central test registry, where they are available for execution based solely on their test name. The test name is interoperable with the names CMake is aware of, so CTest is able to run the tests one by one in the combined binary. Task-number: QTBUG-105273 Change-Id: I2b6071d58be16979bd967eab2d405249f5a4e658 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
2022-07-12 16:15:24 +00:00
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
# Don't try to extend_target when cross compiling an imported host target (like a tool).
qt_is_imported_target("${target}" is_imported)
if(is_imported)
return()
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
set(option_args
NO_UNITY_BUILD
CMake: Allow specifying most SBOM options to qt_internal_add_foo Previously, only a very short subset of options related to attribution files could be specified to qt_internal_add_module / qt_internal_extend_target. It is more convenient to allow specifying most (safe) options, instead of calling another function. Unsafe are considered paths like INSTALL_PATH and derivatives, TYPE which is too generic, and some other ones like LIBRARIES which would be duplicated, and causes warnings in cmake_parse_arguments if duplicated. Change the code to allow specifying most SBOM options and forwarding them to _qt_internal_extend_sbom. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I6eb723e165edf59973d83c66eace43acdce237de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-06-14 17:07:16 +00:00
${__qt_internal_sbom_optional_args}
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
)
Cleanup qt_internal_extend_target function Extract function arguments to the corresponding variables and use variables when parsing arguments. Remove whitespace between if keyword and parentheses. Adjust size of code lines. Document function-specific arguments. Change-Id: I1c77fbf268618a844726683768575aff05894c70 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 12:38:23 +00:00
set(single_args
PRECOMPILED_HEADER
CMake: prefix elf to linker script keywords/properties The linker script properties/keywords are only used for elf targets, so we rename them to make the code more expressive. Pick-to: 6.10 Change-Id: I94cf843c78bb8d9650807e3b9584b1b983c3cf47 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-08-12 05:50:55 +00:00
EXTRA_ELF_LINKER_SCRIPT_CONTENT
CMake: support reduced relocations for namespaced Qt The dynlist files passed to the linker have hardcoded function names that do not take namespacing into account. We therefore generate the dynlist files at configure time from the qt namespace. Task-number: QTBUG-138543 Pick-to: 6.10 Change-Id: Ib3521b83942548cb09c11687e1701c2308f9d148 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-08-07 02:12:26 +00:00
ELF_LINKER_DYNAMIC_LIST
CMake: Allow specifying most SBOM options to qt_internal_add_foo Previously, only a very short subset of options related to attribution files could be specified to qt_internal_add_module / qt_internal_extend_target. It is more convenient to allow specifying most (safe) options, instead of calling another function. Unsafe are considered paths like INSTALL_PATH and derivatives, TYPE which is too generic, and some other ones like LIBRARIES which would be duplicated, and causes warnings in cmake_parse_arguments if duplicated. Change the code to allow specifying most SBOM options and forwarding them to _qt_internal_extend_sbom. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I6eb723e165edf59973d83c66eace43acdce237de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-06-14 17:07:16 +00:00
${__qt_internal_sbom_single_args}
Cleanup qt_internal_extend_target function Extract function arguments to the corresponding variables and use variables when parsing arguments. Remove whitespace between if keyword and parentheses. Adjust size of code lines. Document function-specific arguments. Change-Id: I1c77fbf268618a844726683768575aff05894c70 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 12:38:23 +00:00
)
set(multi_args
${__default_public_args}
${__default_private_args}
${__default_private_module_args}
CONDITION
Add CONDITION_INDEPENDENT_SOURCES argument to qt_internal_extend_target The argument allows to ignore the condition for source files if they are used in the Qt code without corresponding guards. The header files of this kind usually have internal guards, that suppress the error at the location where they are used, so AUTOGEN is skipped for these header files to suppress the warnings from CMake. If file belongs to a module, it will display AUTHOR_WARNING which should urge Qt maintainers to guard the use of the source file properly. Task-number: QTBUG-103196 Change-Id: I7b4c12031a5d19ff15868d4782c0d396ef7aed8c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2022-11-03 15:38:51 +00:00
CONDITION_INDEPENDENT_SOURCES
Cleanup qt_internal_extend_target function Extract function arguments to the corresponding variables and use variables when parsing arguments. Remove whitespace between if keyword and parentheses. Adjust size of code lines. Document function-specific arguments. Change-Id: I1c77fbf268618a844726683768575aff05894c70 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 12:38:23 +00:00
COMPILE_FLAGS
CMake: prefix elf to linker script keywords/properties The linker script properties/keywords are only used for elf targets, so we rename them to make the code more expressive. Pick-to: 6.10 Change-Id: I94cf843c78bb8d9650807e3b9584b1b983c3cf47 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-08-12 05:50:55 +00:00
EXTRA_ELF_LINKER_SCRIPT_EXPORTS
CMake: Allow specifying most SBOM options to qt_internal_add_foo Previously, only a very short subset of options related to attribution files could be specified to qt_internal_add_module / qt_internal_extend_target. It is more convenient to allow specifying most (safe) options, instead of calling another function. Unsafe are considered paths like INSTALL_PATH and derivatives, TYPE which is too generic, and some other ones like LIBRARIES which would be duplicated, and causes warnings in cmake_parse_arguments if duplicated. Change the code to allow specifying most SBOM options and forwarding them to _qt_internal_extend_sbom. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I6eb723e165edf59973d83c66eace43acdce237de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-06-14 17:07:16 +00:00
${__qt_internal_sbom_multi_args}
Cleanup qt_internal_extend_target function Extract function arguments to the corresponding variables and use variables when parsing arguments. Remove whitespace between if keyword and parentheses. Adjust size of code lines. Document function-specific arguments. Change-Id: I1c77fbf268618a844726683768575aff05894c70 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 12:38:23 +00:00
)
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
Cleanup qt_internal_extend_target function Extract function arguments to the corresponding variables and use variables when parsing arguments. Remove whitespace between if keyword and parentheses. Adjust size of code lines. Document function-specific arguments. Change-Id: I1c77fbf268618a844726683768575aff05894c70 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 12:38:23 +00:00
"${option_args}"
"${single_args}"
"${multi_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_validate_all_args_are_parsed(arg)
Cleanup qt_internal_extend_target function Extract function arguments to the corresponding variables and use variables when parsing arguments. Remove whitespace between if keyword and parentheses. Adjust size of code lines. Document function-specific arguments. Change-Id: I1c77fbf268618a844726683768575aff05894c70 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 12:38:23 +00:00
if("x${arg_CONDITION}" STREQUAL "x")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
set(arg_CONDITION ON)
endif()
qt_evaluate_config_expression(result ${arg_CONDITION})
Cleanup qt_internal_extend_target function Extract function arguments to the corresponding variables and use variables when parsing arguments. Remove whitespace between if keyword and parentheses. Adjust size of code lines. Document function-specific arguments. Change-Id: I1c77fbf268618a844726683768575aff05894c70 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 12:38:23 +00:00
if(${result})
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(QT_CMAKE_DEBUG_EXTEND_TARGET)
message("qt_extend_target(${target} CONDITION ${arg_CONDITION} ...): Evaluated")
endif()
set(dbus_sources "")
foreach(adaptor ${arg_DBUS_ADAPTOR_SOURCES})
CMake: Fix CMP0174 warnings CMake 3.31 introduced the policy CMP0174 that triggers a warning if a single-value argument is passed to a function without a value. We did this doing this when forwarding arguments in code that doesn't use _qt_internal_forward_function_args yet, e.g. in qt_internal_add_app: qt_internal_add_executable(... TARGET_PRODUCT ${arg_TARGET_PRODUCT} ...) Forward the warning-triggering arguments with _qt_internal_forward_function_args now, because that only forwards used arguments. In the future, we can offload more forwarding work to the _qt_internal_forward_function_args command and simplify the forwarding code in qt_internal_add_app and qt_internal_add_tool. This patch only fixes the worst offenders for now. Pick-to: 6.8 Change-Id: Ie786691e4b236decf4c62f4dd0751ed76b721177 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-11-08 13:26:32 +00:00
_qt_internal_forward_function_args(
FORWARD_PREFIX arg_DBUS_ADAPTOR
FORWARD_OUT_VAR forwarded_args
FORWARD_SINGLE
BASENAME
FLAGS
Cleanup qt_internal_extend_target function Extract function arguments to the corresponding variables and use variables when parsing arguments. Remove whitespace between if keyword and parentheses. Adjust size of code lines. Document function-specific arguments. Change-Id: I1c77fbf268618a844726683768575aff05894c70 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 12:38:23 +00:00
)
CMake: Fix CMP0174 warnings CMake 3.31 introduced the policy CMP0174 that triggers a warning if a single-value argument is passed to a function without a value. We did this doing this when forwarding arguments in code that doesn't use _qt_internal_forward_function_args yet, e.g. in qt_internal_add_app: qt_internal_add_executable(... TARGET_PRODUCT ${arg_TARGET_PRODUCT} ...) Forward the warning-triggering arguments with _qt_internal_forward_function_args now, because that only forwards used arguments. In the future, we can offload more forwarding work to the _qt_internal_forward_function_args command and simplify the forwarding code in qt_internal_add_app and qt_internal_add_tool. This patch only fixes the worst offenders for now. Pick-to: 6.8 Change-Id: Ie786691e4b236decf4c62f4dd0751ed76b721177 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-11-08 13:26:32 +00:00
qt_create_qdbusxml2cpp_command("${target}" "${adaptor}" ADAPTOR ${forwarded_args})
CMake: Fix dbus headers not being added in qt_internal_extend_target The generated dbus headers would not appear in IDE source lists because of incorrectly named variables. Pick-to: 6.2 6.3 Change-Id: I276d4284eb94b98cc75f791de62ca332ad947004 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-01-17 15:59:05 +00:00
list(APPEND dbus_sources "${adaptor}")
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
endforeach()
foreach(interface ${arg_DBUS_INTERFACE_SOURCES})
CMake: Fix CMP0174 warnings CMake 3.31 introduced the policy CMP0174 that triggers a warning if a single-value argument is passed to a function without a value. We did this doing this when forwarding arguments in code that doesn't use _qt_internal_forward_function_args yet, e.g. in qt_internal_add_app: qt_internal_add_executable(... TARGET_PRODUCT ${arg_TARGET_PRODUCT} ...) Forward the warning-triggering arguments with _qt_internal_forward_function_args now, because that only forwards used arguments. In the future, we can offload more forwarding work to the _qt_internal_forward_function_args command and simplify the forwarding code in qt_internal_add_app and qt_internal_add_tool. This patch only fixes the worst offenders for now. Pick-to: 6.8 Change-Id: Ie786691e4b236decf4c62f4dd0751ed76b721177 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-11-08 13:26:32 +00:00
_qt_internal_forward_function_args(
FORWARD_PREFIX arg_DBUS_INTERFACE
FORWARD_OUT_VAR forwarded_args
FORWARD_SINGLE
BASENAME
FLAGS
Cleanup qt_internal_extend_target function Extract function arguments to the corresponding variables and use variables when parsing arguments. Remove whitespace between if keyword and parentheses. Adjust size of code lines. Document function-specific arguments. Change-Id: I1c77fbf268618a844726683768575aff05894c70 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 12:38:23 +00:00
)
CMake: Fix CMP0174 warnings CMake 3.31 introduced the policy CMP0174 that triggers a warning if a single-value argument is passed to a function without a value. We did this doing this when forwarding arguments in code that doesn't use _qt_internal_forward_function_args yet, e.g. in qt_internal_add_app: qt_internal_add_executable(... TARGET_PRODUCT ${arg_TARGET_PRODUCT} ...) Forward the warning-triggering arguments with _qt_internal_forward_function_args now, because that only forwards used arguments. In the future, we can offload more forwarding work to the _qt_internal_forward_function_args command and simplify the forwarding code in qt_internal_add_app and qt_internal_add_tool. This patch only fixes the worst offenders for now. Pick-to: 6.8 Change-Id: Ie786691e4b236decf4c62f4dd0751ed76b721177 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-11-08 13:26:32 +00:00
qt_create_qdbusxml2cpp_command("${target}" "${interface}" INTERFACE ${forwarded_args})
CMake: Fix dbus headers not being added in qt_internal_extend_target The generated dbus headers would not appear in IDE source lists because of incorrectly named variables. Pick-to: 6.2 6.3 Change-Id: I276d4284eb94b98cc75f791de62ca332ad947004 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-01-17 15:59:05 +00:00
list(APPEND dbus_sources "${interface}")
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
endforeach()
Make sure that the generated dbus sources get extra compiler flags Process the regular SOURCES and DBus sources the same way in the qt_internal_extend_target call. Previously the specified COMPILE_FLAGS had no effect on DBus sources. [ChangeLog][General] The internal DBus source files that are generated, now are compiled with the same set of compilation flags and options as other source files of the Qt module. Change-Id: I9bdeb8f45c6af1b0cb0235425b0ff7efcb952d59 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 16:00:24 +00:00
set(all_sources
${arg_SOURCES}
${dbus_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
get_target_property(target_type ${target} TYPE)
set(is_library FALSE)
Remove HEADER_MODULE from qt_internal_extend_target The current qt_internal_extend_target interface expects that the caller will pass the HEADER_MODULE argument on each call. This is not correct, since the argument doesn't affect the target internals, but only help to decide how to modify the target according to its type. The target type meanwhile can be always read from target properties. So this solution is more consistent. Change-Id: Ie84a2226ceb71cb5272670e5d43bdfc7a101360a Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-08-10 13:58:15 +00:00
set(is_interface_lib FALSE)
Fix the static linking of plugins to the Qt tools and internal executables Qt tools and executables may required the static plugins from modules that are build as part of the Qt build tree. In this case we need to force plugin importing. This adds the qt_internal_import_plugins call when we extend the executable target. Replace the previos solution that considered libraries that were provided in the arguments of the qt_internal_add_executable call only. Pick-to: 6.7 6.6 6.5 Fixes: QTBUG-111988 Change-Id: Ifa2cf7f1f68d9f90cafc64f225aebe11d4cdb2ae Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-03-27 17:55:40 +00:00
set(is_executable FALSE)
Cleanup qt_internal_extend_target function Extract function arguments to the corresponding variables and use variables when parsing arguments. Remove whitespace between if keyword and parentheses. Adjust size of code lines. Document function-specific arguments. Change-Id: I1c77fbf268618a844726683768575aff05894c70 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 12:38:23 +00:00
if(${target_type} STREQUAL "STATIC_LIBRARY" OR ${target_type} STREQUAL "SHARED_LIBRARY")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
set(is_library TRUE)
Remove HEADER_MODULE from qt_internal_extend_target The current qt_internal_extend_target interface expects that the caller will pass the HEADER_MODULE argument on each call. This is not correct, since the argument doesn't affect the target internals, but only help to decide how to modify the target according to its type. The target type meanwhile can be always read from target properties. So this solution is more consistent. Change-Id: Ie84a2226ceb71cb5272670e5d43bdfc7a101360a Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-08-10 13:58:15 +00:00
elseif(target_type STREQUAL "INTERFACE_LIBRARY")
set(is_interface_lib TRUE)
Fix the static linking of plugins to the Qt tools and internal executables Qt tools and executables may required the static plugins from modules that are build as part of the Qt build tree. In this case we need to force plugin importing. This adds the qt_internal_import_plugins call when we extend the executable target. Replace the previos solution that considered libraries that were provided in the arguments of the qt_internal_add_executable call only. Pick-to: 6.7 6.6 6.5 Fixes: QTBUG-111988 Change-Id: Ifa2cf7f1f68d9f90cafc64f225aebe11d4cdb2ae Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-03-27 17:55:40 +00:00
elseif(target_type STREQUAL "EXECUTABLE")
set(is_executable TRUE)
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()
Remove HEADER_MODULE from qt_internal_extend_target The current qt_internal_extend_target interface expects that the caller will pass the HEADER_MODULE argument on each call. This is not correct, since the argument doesn't affect the target internals, but only help to decide how to modify the target according to its type. The target type meanwhile can be always read from target properties. So this solution is more consistent. Change-Id: Ie84a2226ceb71cb5272670e5d43bdfc7a101360a Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-08-10 13:58:15 +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
foreach(lib ${arg_PUBLIC_LIBRARIES} ${arg_LIBRARIES})
CMake: Fix excessive size of precompiled header files Do not add catch-all header files like QtCore, QtGui, etc. to precompiled headers for targets that already define their own set of precompiled header files. This reduces the size of the precompiled headers and brings the pch file sizes down into the region of the qmake build. Pick-to: 6.2 Task-number: QTBUG-89122 Change-Id: I8e4d17aa6829c7d7b1aa01a01a61b6677e22c460 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-23 19:12:36 +00:00
# Automatically generate PCH for 'target' using public dependencies.
# But only if 'target' is a library/module that does not specify its own PCH file.
if(NOT arg_PRECOMPILED_HEADER AND ${is_library})
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_update_precompiled_header_with_library("${target}" "${lib}")
endif()
string(REGEX REPLACE "_nolink$" "" base_lib "${lib}")
if(NOT base_lib STREQUAL lib)
qt_create_nolink_target("${base_lib}" ${target})
endif()
Collect module_sync_headers targets from the target deps Use the internal target property to store the module_sync_header target name. The property then is used to collect module_sync_header targets and build the dependency tree between them. This mechanism only works for Qt dependencies that are added using qt_internal_extend_target call that works well at least for out CI builds. The mechanism allows to omit the race in sync_header runs that might lead to unexpected results since internal targets like automoc or headersclean_check only depend directly on module_sync_header target that belong to the module. Change-Id: I564f3ea0f3c1703e70c4c300fd1307c3214d39d8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-05-25 17:32:12 +00:00
# Collect _sync_headers targets from libraries that the target depends on. This is
# heuristic way of building the dependency tree between the _sync_headers targets of
# different Qt modules.
if(TARGET "${lib}")
Cut off the IMPORTED targets from the sync header dependencies IMPORTED targets obviously have nothing to sync. So we should ignore them when collecting dependencies for header sync. Pick-to: 6.5 6.6 6.7 Change-Id: Ief68ff5eb2eb13a3fe1608445e8f5e6abb5971b4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-01-17 06:40:48 +00:00
get_target_property(is_imported ${lib} IMPORTED)
if(NOT is_imported)
get_target_property(is_private ${lib} _qt_is_private_module)
if(is_private)
get_target_property(lib ${lib} _qt_public_module_target_name)
endif()
set(out_genex "$<TARGET_PROPERTY:${lib},_qt_internal_sync_headers_target>")
set_property(TARGET ${target}
APPEND PROPERTY _qt_internal_sync_headers_deps "${out_genex}")
Fix standalone headersclean_check targets If module depends on some module Private part only the sync_headers dependencies from this public part of this Private module is skipped. Check if the module is Private and use the public module to read the _qt_internal_sync_headers_target property. Amends 0006a564c85d49153288cd3834197effed53394e Fixes: QTBUG-115712 Pick-to: 6.6 Change-Id: I4678e2a6c9ec8f80862a97d48f0a3b4214ae2307 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-08-02 13:18:15 +00:00
endif()
Collect module_sync_headers targets from the target deps Use the internal target property to store the module_sync_header target name. The property then is used to collect module_sync_header targets and build the dependency tree between them. This mechanism only works for Qt dependencies that are added using qt_internal_extend_target call that works well at least for out CI builds. The mechanism allows to omit the race in sync_header runs that might lead to unexpected results since internal targets like automoc or headersclean_check only depend directly on module_sync_header target that belong to the module. Change-Id: I564f3ea0f3c1703e70c4c300fd1307c3214d39d8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-05-25 17:32:12 +00:00
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
endforeach()
Force linking against versioned libraries when building Qt artifacts Replace Qt:: namespace with Qt6:: namespace in target_link_libraries for the Qt modules/plugins/libraries. Fixes: QTBUG-114706 Change-Id: Idfd0917dbe1a6a266bc4e9d5f465e550788b5aaf Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-02-12 08:36:50 +00:00
list(TRANSFORM arg_PUBLIC_LIBRARIES REPLACE "^Qt::" "${QT_CMAKE_EXPORT_NAMESPACE}::")
list(TRANSFORM arg_LIBRARIES REPLACE "^Qt::" "${QT_CMAKE_EXPORT_NAMESPACE}::")
CMake: Only load Qt6FooPrivate automatically when building Qt [ChangeLog][CMake] CMake packages of public Qt modules don't provide the targets of their private counterparts anymore. User projects must now call find_package(Qt6 COMPONENTS FooPrivate) to make use of the Qt6::FooPrivate target. User projects that rely on the old behavior can set the CMake variable QT_FIND_PRIVATE_MODULES to ON. For user projects, the warning message we know from QMake is displayed. The warning can be disabled by setting the CMake variable QT_NO_PRIVATE_MODULE_WARNING to ON. Within Qt itself, find_package(Qt6Foo) will still find_package(Qt6FooPrivate). For static Qt builds, we need to wrap usage of private Qt modules in $<BUILD_INTERFACE> or $<BUILD_LOCAL_INTERFACE> (if CMake's version is >= 3.26). Static builds with CMake < 3.26 will always load the private modules if the Qt6FooConfig.cmake from Qt's build tree is loaded. This is the case in non-prefix builds and (in the future) when building examples as external project. This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-03 16:19:22 +00:00
qt_internal_wrap_private_modules(arg_LIBRARIES ${arg_LIBRARIES})
Force linking against versioned libraries when building Qt artifacts Replace Qt:: namespace with Qt6:: namespace in target_link_libraries for the Qt modules/plugins/libraries. Fixes: QTBUG-114706 Change-Id: Idfd0917dbe1a6a266bc4e9d5f465e550788b5aaf Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-02-12 08:36:50 +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
# Set-up the target
Exclude sources from HEADER_MODULE if cmake version is less than 3.19 CMake versions less than 3.19 don't support adding the source files to the PRIVATE scope of the INTERFACE libraries. It looks like these PRIVATE sources are only used by IDEs to display them in a project tree. Skip them to avoid configuring issues. Fixes: QTBUG-99316 Pick-to: 6.3 Change-Id: Id03f540ac9c94e920adfae5de4f364bd7aba4613 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-12-21 16:05:07 +00:00
# CMake versions less than 3.19 don't support adding the source files to the PRIVATE scope
# of the INTERFACE libraries. These PRIVATE sources are only needed by IDEs to display
# them in a project tree, so to avoid build issues and appearing the sources in
Add possibility to store source files for interface targets Add source files to the _qt_internal_target_sources property, when running qt_internal_extend_target on interface libraries instead of ignoring sources for CMake versions that don't support non-interface properties. The property is not full-functional, but still allows to execute internal routines on target sources. Also add qt_internal_get_target_sources_property function that helps to destinguish which property stores target sources. Task-number: QTBUG-103196 Change-Id: I435c558090a24a7988f1a1c49f924dc195e72480 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-10 15:21:18 +00:00
# INTERFACE_SOURCES property of INTERFACE_LIBRARY. Collect them inside the
# _qt_internal_target_sources property, since they can be useful in the source processing
# functions. The property itself is not exported and should only be used in the Qt internal
# build tree.
Remove HEADER_MODULE from qt_internal_extend_target The current qt_internal_extend_target interface expects that the caller will pass the HEADER_MODULE argument on each call. This is not correct, since the argument doesn't affect the target internals, but only help to decide how to modify the target according to its type. The target type meanwhile can be always read from target properties. So this solution is more consistent. Change-Id: Ie84a2226ceb71cb5272670e5d43bdfc7a101360a Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-08-10 13:58:15 +00:00
if(NOT is_interface_lib OR CMAKE_VERSION VERSION_GREATER_EQUAL "3.19")
Make sure that the generated dbus sources get extra compiler flags Process the regular SOURCES and DBus sources the same way in the qt_internal_extend_target call. Previously the specified COMPILE_FLAGS had no effect on DBus sources. [ChangeLog][General] The internal DBus source files that are generated, now are compiled with the same set of compilation flags and options as other source files of the Qt module. Change-Id: I9bdeb8f45c6af1b0cb0235425b0ff7efcb952d59 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 16:00:24 +00:00
target_sources("${target}" PRIVATE ${all_sources})
Cleanup qt_internal_extend_target function Extract function arguments to the corresponding variables and use variables when parsing arguments. Remove whitespace between if keyword and parentheses. Adjust size of code lines. Document function-specific arguments. Change-Id: I1c77fbf268618a844726683768575aff05894c70 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 12:38:23 +00:00
if(arg_COMPILE_FLAGS)
Make sure that the generated dbus sources get extra compiler flags Process the regular SOURCES and DBus sources the same way in the qt_internal_extend_target call. Previously the specified COMPILE_FLAGS had no effect on DBus sources. [ChangeLog][General] The internal DBus source files that are generated, now are compiled with the same set of compilation flags and options as other source files of the Qt module. Change-Id: I9bdeb8f45c6af1b0cb0235425b0ff7efcb952d59 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 16:00:24 +00:00
set_source_files_properties(${all_sources} PROPERTIES
Exclude sources from HEADER_MODULE if cmake version is less than 3.19 CMake versions less than 3.19 don't support adding the source files to the PRIVATE scope of the INTERFACE libraries. It looks like these PRIVATE sources are only used by IDEs to display them in a project tree. Skip them to avoid configuring issues. Fixes: QTBUG-99316 Pick-to: 6.3 Change-Id: Id03f540ac9c94e920adfae5de4f364bd7aba4613 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-12-21 16:05:07 +00:00
COMPILE_FLAGS "${arg_COMPILE_FLAGS}")
endif()
Add possibility to store source files for interface targets Add source files to the _qt_internal_target_sources property, when running qt_internal_extend_target on interface libraries instead of ignoring sources for CMake versions that don't support non-interface properties. The property is not full-functional, but still allows to execute internal routines on target sources. Also add qt_internal_get_target_sources_property function that helps to destinguish which property stores target sources. Task-number: QTBUG-103196 Change-Id: I435c558090a24a7988f1a1c49f924dc195e72480 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-10 15:21:18 +00:00
else()
set_property(TARGET ${target} APPEND PROPERTY
Make sure that the generated dbus sources get extra compiler flags Process the regular SOURCES and DBus sources the same way in the qt_internal_extend_target call. Previously the specified COMPILE_FLAGS had no effect on DBus sources. [ChangeLog][General] The internal DBus source files that are generated, now are compiled with the same set of compilation flags and options as other source files of the Qt module. Change-Id: I9bdeb8f45c6af1b0cb0235425b0ff7efcb952d59 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 16:00:24 +00:00
_qt_internal_target_sources ${all_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
endif()
set(public_visibility_option "PUBLIC")
set(private_visibility_option "PRIVATE")
Remove HEADER_MODULE from qt_internal_extend_target The current qt_internal_extend_target interface expects that the caller will pass the HEADER_MODULE argument on each call. This is not correct, since the argument doesn't affect the target internals, but only help to decide how to modify the target according to its type. The target type meanwhile can be always read from target properties. So this solution is more consistent. Change-Id: Ie84a2226ceb71cb5272670e5d43bdfc7a101360a Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-08-10 13:58:15 +00:00
if(is_interface_lib)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
set(public_visibility_option "INTERFACE")
set(private_visibility_option "INTERFACE")
endif()
target_include_directories("${target}"
${public_visibility_option} ${arg_PUBLIC_INCLUDE_DIRECTORIES}
${private_visibility_option} ${arg_INCLUDE_DIRECTORIES})
CMake: add SYSTEM_INCLUDE_DIRECTORIES to qt_internal_extend_target This allows one to add an extra set of directories to the build, but let the compiler know that they are system paths (that is, the compiler should refrain from emitting warnings in code found there). This extends INCLUDE_DIRECTORIES and is by necessity a private include set. Will be used by qtquick3dphysics, due to its PhysX dependency. Change-Id: I76216ced393445a4ae2dfffd1729c556db0cce3d Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-11-22 01:55:13 +00:00
target_include_directories("${target}" SYSTEM
${private_visibility_option} ${arg_SYSTEM_INCLUDE_DIRECTORIES})
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
target_compile_definitions("${target}"
${public_visibility_option} ${arg_PUBLIC_DEFINES}
${private_visibility_option} ${arg_DEFINES})
target_link_libraries("${target}"
${public_visibility_option} ${arg_PUBLIC_LIBRARIES}
${private_visibility_option} ${arg_LIBRARIES})
target_compile_options("${target}"
${public_visibility_option} ${arg_PUBLIC_COMPILE_OPTIONS}
${private_visibility_option} ${arg_COMPILE_OPTIONS})
target_link_options("${target}"
${public_visibility_option} ${arg_PUBLIC_LINK_OPTIONS}
${private_visibility_option} ${arg_LINK_OPTIONS})
Remove HEADER_MODULE from qt_internal_extend_target The current qt_internal_extend_target interface expects that the caller will pass the HEADER_MODULE argument on each call. This is not correct, since the argument doesn't affect the target internals, but only help to decide how to modify the target according to its type. The target type meanwhile can be always read from target properties. So this solution is more consistent. Change-Id: Ie84a2226ceb71cb5272670e5d43bdfc7a101360a Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-08-10 13:58:15 +00:00
if(NOT is_interface_lib)
cmake: Unify the set flags between AUTOMOC and qt_wrap_cpp For AUTOMOC, we were missing the compiler flavor flag, as well as the WIN32 define. While the latter has not caused any known issues yet, the former is rather problematic for implementing __has_include in moc. Note that this only applies in the case where the AUTOMOC flags are set by us in a qt_ function like qt_add_excutable. Plain add_executable won't benefit from it, but we already mention that Qt targets should not use plain CMake functions. This change is (indirectly) tested by the commit adding __has_include support for moc. Task-number: QTBUG-136097 Pick-to: 6.10 6.9 6.8 Change-Id: Ie2beb08a44a3a67e3bc363d9c1ba93b7d6a49133 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-05-27 09:30:37 +00:00
_qt_internal_get_moc_compiler_flavor_flags(flavor_flags)
Cleanup qt_internal_extend_target function Extract function arguments to the corresponding variables and use variables when parsing arguments. Remove whitespace between if keyword and parentheses. Adjust size of code lines. Document function-specific arguments. Change-Id: I1c77fbf268618a844726683768575aff05894c70 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-14 12:38:23 +00:00
set_property(TARGET "${target}" APPEND PROPERTY
cmake: Unify the set flags between AUTOMOC and qt_wrap_cpp For AUTOMOC, we were missing the compiler flavor flag, as well as the WIN32 define. While the latter has not caused any known issues yet, the former is rather problematic for implementing __has_include in moc. Note that this only applies in the case where the AUTOMOC flags are set by us in a qt_ function like qt_add_excutable. Plain add_executable won't benefit from it, but we already mention that Qt targets should not use plain CMake functions. This change is (indirectly) tested by the commit adding __has_include support for moc. Task-number: QTBUG-136097 Pick-to: 6.10 6.9 6.8 Change-Id: Ie2beb08a44a3a67e3bc363d9c1ba93b7d6a49133 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-05-27 09:30:37 +00:00
AUTOMOC_MOC_OPTIONS "${arg_MOC_OPTIONS}" ${flavor_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
)
cmake: Unify the set flags between AUTOMOC and qt_wrap_cpp For AUTOMOC, we were missing the compiler flavor flag, as well as the WIN32 define. While the latter has not caused any known issues yet, the former is rather problematic for implementing __has_include in moc. Note that this only applies in the case where the AUTOMOC flags are set by us in a qt_ function like qt_add_excutable. Plain add_executable won't benefit from it, but we already mention that Qt targets should not use plain CMake functions. This change is (indirectly) tested by the commit adding __has_include support for moc. Task-number: QTBUG-136097 Pick-to: 6.10 6.9 6.8 Change-Id: Ie2beb08a44a3a67e3bc363d9c1ba93b7d6a49133 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-05-27 09:30:37 +00:00
cmake: Teach qt_internal_extend_target about PLUGIN_TYPES Change-Id: I2e8a3faa6ada66a644dceeb98f9ba8e994db4192 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-25 13:28:31 +00:00
# Plugin types associated to a module
if(NOT "x${arg_PLUGIN_TYPES}" STREQUAL "x")
qt_internal_add_plugin_types("${target}" "${arg_PLUGIN_TYPES}")
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
endif()
# When computing the private library dependencies, we need to check not only the known
# modules added by this repo's qt_build_repo(), but also all module dependencies that
# were found via find_package().
qt_internal_get_qt_all_known_modules(known_modules)
# When a public module depends on a private module (Gui on CorePrivate)
# make its private module depend on the other private module (GuiPrivate will depend on
# CorePrivate).
set(qt_libs_private "")
foreach(it ${known_modules})
list(FIND arg_LIBRARIES "Qt::${it}Private" pos)
if(pos GREATER -1)
list(APPEND qt_libs_private "Qt::${it}Private")
endif()
endforeach()
CMake: Generate an SPDX v2.3 SBOM file for each built repository This change adds a new -sbom configure option to allow generating and installing an SPDX v2.3 SBOM file when building a qt repo. The -sbom-dir option can be used to configure the location where each repo sbom file will be installed. By default it is installed into $prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx which is basically ~/Qt/sbom/qtbase-6.8.0.spdx The file is installed as part of the default installation rules, but it can also be installed manually using the "sbom" installation component, or "sbom_$lower_project_name" in a top-level build. For example: cmake install . --component sbom_qtbase CMake 3.19+ is needed to read the qt_attribution.json files for copyrights, license info, etc. When using an older cmake version, configuration will error out. It is possible to opt into using an older cmake version, but the generated sbom will lack all the attribution file information. Using an older cmake version is untested and not officially supported. Implementation notes. The bulk of the implementation is split into 4 new files: - QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing and dispatching the generation of various pieces of the SBOM document e.g. a SDPX package associated with a target like Core, a SDPX file entry for each target binary file (per-config shared library, archive, executable, etc) - QtPublicSbomGenerationHelpers.cmake - for non-Qt specific implementation of SPDX generation. This also has some code that was taken from the cmake-sbom 3rd party project, so it is dual licensed under the usual Qt build system BSD license, as well as the MIT license of the 3rd party project - QtPublicGitHelpers.cmake - for git related features, mainly to embed queried hashes or tags into version strings, is dual-licensed for the same reasons as QtPublicSbomGenerationHelpers.cmake - QtSbomHelpers.cmake - Qt-specific functions that just forward arguments to the public functions. These are meant to be used in our Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones for naming consistency. These function would mostly be used to annotate 3rd party libraries with sbom info and to add sbom info for unusual target setups (like the Bootstrap library), because most of the handling is already done automatically via qt_internal_add_module/plugin/etc. The files are put into Public cmake files, with the future hope of making this available to user projects in some capacity. The distinction of Qt-specific and non-Qt specific code might blur a bit, and thus the separation across files might not always be consistent, but it was best effort. The main purpose of the code is to collect various information about targets and their relationships and generate equivalent SPDX info. Collection is currently done for the following targets: Qt modules, plugins, apps, tools, system libraries, bundled 3rd party libraries and partial 3rd party sources compiled directly as part of Qt targets. Each target has an equivalent SPDX package generated with information like version, license, copyright, CPE (common vulnerability identifier), files that belong to the package, and relationships on other SPDX packages (associated cmake targets), mostly gathered from direct linking dependencies. Each package might also contain files, e.g. libQt6Core.so for the Core target. Each file also has info like license id, copyrights, but also the list of source files that were used to generate the file and a sha1 checksum. SPDX documents can also refer to packages in other SPDX documents, and those are referred to via external document references. This is the case when building qtdeclarative and we refer to Core. For qt provided targets, we have complete information regarding licenses, and copyrights. For bundled 3rd party libraries, we should also have most information, which is usually parsed from the src/3rdparty/libfoo/qt_attribution.json files. If there are multiple attribution files, or if the files have multiple entries, we create a separate SBOM package for each of those entries, because each might have a separate copyright or version, and an sbom package can have only one version (although many copyrights). For system libraries we usually lack the information because we don't have attribution files for Find scripts. So the info needs to be manually annotated via arguments to the sbom function calls, or the FindFoo.cmake scripts expose that information in some form and we can query it. There are also corner cases like 3rdparty sources being directly included in a Qt library, like the m4dc files for Gui, or PCRE2 for Bootstrap. Or QtWebEngine libraries (either Qt bundled or Chromium bundled or system libraries) which get linked in by GN instead of CMake, so there are no direct targets for them. The information for these need to be annotated manually as well. There is also a distinction to be made for static Qt builds (or any static Qt library in a shared build), where the system libraries found during the Qt build might not be the same that are linked into the final user application or library. The actual generation of the SBOM is done by file(GENERATE)-ing one .cmake file for each target, file, external ref, etc, which will be included in a top-level cmake script. The top-level cmake script will run through each included file, to append to a "staging" spdx file, which will then be used in a configure_file() call to replace some final variables, like embedding a file checksum. There are install rules to generate a complete SBOM during installation, and an optional 'sbom' custom target that allows building an incomplete SBOM during the build step. The build target is just for convenience and faster development iteration time. It is incomplete because it is missing the installed file SHA1 checksums and the document verification code (the sha1 of all sha1s). We can't compute those during the build before the files are actually installed. A complete SBOM can only be achieved at installation time. The install script will include all the generated helper files, but also set some additional variables to ensure checksumming happens, and also handle multi-config installation, among other small things. For multi-config builds, CMake doesn't offer a way to run code after all configs are installed, because they might not always be installed, someone might choose to install just Release. To handle that, we rely on ninja installing each config sequentially (because ninja places the install rules into the 'console' pool which runs one task at a time). For each installed config we create a config-specific marker file. Once all marker files are present, whichever config ends up being installed as the last one, we run the sbom generation once, and then delete all marker files. There are a few internal variables that can be set during configuration to enable various checks (and other features) on the generated spdx files: - QT_INTERNAL_SBOM_VERIFY - QT_INTERNAL_SBOM_AUDIT - QT_INTERNAL_SBOM_AUDIT_NO_ERROR - QT_INTERNAL_SBOM_GENERATE_JSON - QT_INTERNAL_SBOM_SHOW_TABLE - QT_INTERNAL_SBOM_DEFAULT_CHECKS These use 3rd party python tools, so they are not enabled by default. If enabled, they run at installation time after the sbom is installed. We will hopefully enable them in CI. Overall, the code is still a bit messy in a few places, due to time constraints, but can be improved later. Some possible TODOs for the future: - Do we need to handle 3rd party libs linked into a Qt static library in a Qt shared build, where the Qt static lib is not installed, but linked into a Qt shared library, somehow specially? We can record a package for it, but we can't create a spdx file record for it (and associated source relationships) because we don't install the file, and spdx requires the file to be installed and checksummed. Perhaps we can consider adding some free-form text snippet to the package itself? - Do we want to add parsing of .cpp source files for Copyrights, to embed them into the packages? This will likely slow down configuration quite a bit. - Currently sbom info attached to WrapFoo packages in one repo is not exported / available in other repos. E.g. If we annotate WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be available when looking up WrapZLIB in qtimageformats. This is because they are IMPORTED libraries, and are not exported. We might want to record this info in the future. [ChangeLog][Build System] A new -sbom configure option can be used to generate and install a SPDX SBOM (Software Bill of Materials) file for each built Qt repository. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 17:02:56 +00:00
if(arg_LIBRARIES)
_qt_internal_append_to_target_property_without_duplicates(${target}
_qt_extend_target_libraries "${arg_LIBRARIES}"
)
endif()
if(arg_PUBLIC_LIBRARIES)
_qt_internal_append_to_target_property_without_duplicates(${target}
_qt_extend_target_public_libraries "${arg_PUBLIC_LIBRARIES}"
)
endif()
CMake: Work around upstream AUTOGEN issue with discarded dependencies Upstream CMake has a nasty bug where AUTOGEN dependencies are discarded if a library is added as a dependency more than once (or rather the number of times it is added is not equal to the number of configured build configs). This can result in racy build failures, where a <module>_autogen target is supposed to depend on some <other_module>_sync_headers target, but doesn't, and thus moc generates empty metatypes files because it can't find a synced header. To avoid the AUTOGEN dependencies from being discarded, manually add all dependencies passed to qt_internal_extend_target to the AUTOGEN_TARGET_DEPENDS property. The issue is fixed in CMake 4.0, so the workaround is gated on the cmake version used. Add a flag called QT_NO_AUTOGEN_DISCARDED_DEPENDENCIES_WORKAROUND to disable the workaround, in case the fix gets reverted upstream. Pick-to: 6.5 6.8 6.9 Fixes: QTBUG-133725 Change-Id: I857d7e774fc9f9f5203a58311daea5e7177e0d67 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2025-02-14 21:11:28 +00:00
set(all_libraries ${arg_LIBRARIES} ${arg_PUBLIC_LIBRARIES})
CMake: Move qt_internal_work_around_autogen_discarded_dependencies Move it to a public Helpers file, so we can call it also from public API, because there are cases when we need the workaround for public API calls as well. Amends fcb20586316aff2ccc39e2ae840b79f8b0e904a7 Pick-to: 6.5 6.8 6.9 6.10 Task-number: QTBUG-133725 Task-number: QTBUG-137587 Change-Id: I9aef59f5eadc78fd581b24790e6b69795c32c1bf Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-06-27 12:22:00 +00:00
_qt_internal_work_around_autogen_discarded_dependencies(${target} ${all_libraries})
CMake: Work around upstream AUTOGEN issue with discarded dependencies Upstream CMake has a nasty bug where AUTOGEN dependencies are discarded if a library is added as a dependency more than once (or rather the number of times it is added is not equal to the number of configured build configs). This can result in racy build failures, where a <module>_autogen target is supposed to depend on some <other_module>_sync_headers target, but doesn't, and thus moc generates empty metatypes files because it can't find a synced header. To avoid the AUTOGEN dependencies from being discarded, manually add all dependencies passed to qt_internal_extend_target to the AUTOGEN_TARGET_DEPENDS property. The issue is fixed in CMake 4.0, so the workaround is gated on the cmake version used. Add a flag called QT_NO_AUTOGEN_DISCARDED_DEPENDENCIES_WORKAROUND to disable the workaround, in case the fix gets reverted upstream. Pick-to: 6.5 6.8 6.9 Fixes: QTBUG-133725 Change-Id: I857d7e774fc9f9f5203a58311daea5e7177e0d67 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2025-02-14 21:11:28 +00:00
CMake: Allow specifying most SBOM options to qt_internal_add_foo Previously, only a very short subset of options related to attribution files could be specified to qt_internal_add_module / qt_internal_extend_target. It is more convenient to allow specifying most (safe) options, instead of calling another function. Unsafe are considered paths like INSTALL_PATH and derivatives, TYPE which is too generic, and some other ones like LIBRARIES which would be duplicated, and causes warnings in cmake_parse_arguments if duplicated. Change the code to allow specifying most SBOM options and forwarding them to _qt_internal_extend_sbom. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I6eb723e165edf59973d83c66eace43acdce237de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-06-14 17:07:16 +00:00
if(QT_GENERATE_SBOM)
set(sbom_args "")
_qt_internal_forward_function_args(
FORWARD_APPEND
FORWARD_PREFIX arg
FORWARD_OUT_VAR sbom_args
FORWARD_OPTIONS
${__qt_internal_sbom_optional_args}
FORWARD_SINGLE
${__qt_internal_sbom_single_args}
FORWARD_MULTI
${__qt_internal_sbom_multi_args}
CMake: Generate an SPDX v2.3 SBOM file for each built repository This change adds a new -sbom configure option to allow generating and installing an SPDX v2.3 SBOM file when building a qt repo. The -sbom-dir option can be used to configure the location where each repo sbom file will be installed. By default it is installed into $prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx which is basically ~/Qt/sbom/qtbase-6.8.0.spdx The file is installed as part of the default installation rules, but it can also be installed manually using the "sbom" installation component, or "sbom_$lower_project_name" in a top-level build. For example: cmake install . --component sbom_qtbase CMake 3.19+ is needed to read the qt_attribution.json files for copyrights, license info, etc. When using an older cmake version, configuration will error out. It is possible to opt into using an older cmake version, but the generated sbom will lack all the attribution file information. Using an older cmake version is untested and not officially supported. Implementation notes. The bulk of the implementation is split into 4 new files: - QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing and dispatching the generation of various pieces of the SBOM document e.g. a SDPX package associated with a target like Core, a SDPX file entry for each target binary file (per-config shared library, archive, executable, etc) - QtPublicSbomGenerationHelpers.cmake - for non-Qt specific implementation of SPDX generation. This also has some code that was taken from the cmake-sbom 3rd party project, so it is dual licensed under the usual Qt build system BSD license, as well as the MIT license of the 3rd party project - QtPublicGitHelpers.cmake - for git related features, mainly to embed queried hashes or tags into version strings, is dual-licensed for the same reasons as QtPublicSbomGenerationHelpers.cmake - QtSbomHelpers.cmake - Qt-specific functions that just forward arguments to the public functions. These are meant to be used in our Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones for naming consistency. These function would mostly be used to annotate 3rd party libraries with sbom info and to add sbom info for unusual target setups (like the Bootstrap library), because most of the handling is already done automatically via qt_internal_add_module/plugin/etc. The files are put into Public cmake files, with the future hope of making this available to user projects in some capacity. The distinction of Qt-specific and non-Qt specific code might blur a bit, and thus the separation across files might not always be consistent, but it was best effort. The main purpose of the code is to collect various information about targets and their relationships and generate equivalent SPDX info. Collection is currently done for the following targets: Qt modules, plugins, apps, tools, system libraries, bundled 3rd party libraries and partial 3rd party sources compiled directly as part of Qt targets. Each target has an equivalent SPDX package generated with information like version, license, copyright, CPE (common vulnerability identifier), files that belong to the package, and relationships on other SPDX packages (associated cmake targets), mostly gathered from direct linking dependencies. Each package might also contain files, e.g. libQt6Core.so for the Core target. Each file also has info like license id, copyrights, but also the list of source files that were used to generate the file and a sha1 checksum. SPDX documents can also refer to packages in other SPDX documents, and those are referred to via external document references. This is the case when building qtdeclarative and we refer to Core. For qt provided targets, we have complete information regarding licenses, and copyrights. For bundled 3rd party libraries, we should also have most information, which is usually parsed from the src/3rdparty/libfoo/qt_attribution.json files. If there are multiple attribution files, or if the files have multiple entries, we create a separate SBOM package for each of those entries, because each might have a separate copyright or version, and an sbom package can have only one version (although many copyrights). For system libraries we usually lack the information because we don't have attribution files for Find scripts. So the info needs to be manually annotated via arguments to the sbom function calls, or the FindFoo.cmake scripts expose that information in some form and we can query it. There are also corner cases like 3rdparty sources being directly included in a Qt library, like the m4dc files for Gui, or PCRE2 for Bootstrap. Or QtWebEngine libraries (either Qt bundled or Chromium bundled or system libraries) which get linked in by GN instead of CMake, so there are no direct targets for them. The information for these need to be annotated manually as well. There is also a distinction to be made for static Qt builds (or any static Qt library in a shared build), where the system libraries found during the Qt build might not be the same that are linked into the final user application or library. The actual generation of the SBOM is done by file(GENERATE)-ing one .cmake file for each target, file, external ref, etc, which will be included in a top-level cmake script. The top-level cmake script will run through each included file, to append to a "staging" spdx file, which will then be used in a configure_file() call to replace some final variables, like embedding a file checksum. There are install rules to generate a complete SBOM during installation, and an optional 'sbom' custom target that allows building an incomplete SBOM during the build step. The build target is just for convenience and faster development iteration time. It is incomplete because it is missing the installed file SHA1 checksums and the document verification code (the sha1 of all sha1s). We can't compute those during the build before the files are actually installed. A complete SBOM can only be achieved at installation time. The install script will include all the generated helper files, but also set some additional variables to ensure checksumming happens, and also handle multi-config installation, among other small things. For multi-config builds, CMake doesn't offer a way to run code after all configs are installed, because they might not always be installed, someone might choose to install just Release. To handle that, we rely on ninja installing each config sequentially (because ninja places the install rules into the 'console' pool which runs one task at a time). For each installed config we create a config-specific marker file. Once all marker files are present, whichever config ends up being installed as the last one, we run the sbom generation once, and then delete all marker files. There are a few internal variables that can be set during configuration to enable various checks (and other features) on the generated spdx files: - QT_INTERNAL_SBOM_VERIFY - QT_INTERNAL_SBOM_AUDIT - QT_INTERNAL_SBOM_AUDIT_NO_ERROR - QT_INTERNAL_SBOM_GENERATE_JSON - QT_INTERNAL_SBOM_SHOW_TABLE - QT_INTERNAL_SBOM_DEFAULT_CHECKS These use 3rd party python tools, so they are not enabled by default. If enabled, they run at installation time after the sbom is installed. We will hopefully enable them in CI. Overall, the code is still a bit messy in a few places, due to time constraints, but can be improved later. Some possible TODOs for the future: - Do we need to handle 3rd party libs linked into a Qt static library in a Qt shared build, where the Qt static lib is not installed, but linked into a Qt shared library, somehow specially? We can record a package for it, but we can't create a spdx file record for it (and associated source relationships) because we don't install the file, and spdx requires the file to be installed and checksummed. Perhaps we can consider adding some free-form text snippet to the package itself? - Do we want to add parsing of .cpp source files for Copyrights, to embed them into the packages? This will likely slow down configuration quite a bit. - Currently sbom info attached to WrapFoo packages in one repo is not exported / available in other repos. E.g. If we annotate WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be available when looking up WrapZLIB in qtimageformats. This is because they are IMPORTED libraries, and are not exported. We might want to record this info in the future. [ChangeLog][Build System] A new -sbom configure option can be used to generate and install a SPDX SBOM (Software Bill of Materials) file for each built Qt repository. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 17:02:56 +00:00
)
CMake: Allow specifying most SBOM options to qt_internal_add_foo Previously, only a very short subset of options related to attribution files could be specified to qt_internal_add_module / qt_internal_extend_target. It is more convenient to allow specifying most (safe) options, instead of calling another function. Unsafe are considered paths like INSTALL_PATH and derivatives, TYPE which is too generic, and some other ones like LIBRARIES which would be duplicated, and causes warnings in cmake_parse_arguments if duplicated. Change the code to allow specifying most SBOM options and forwarding them to _qt_internal_extend_sbom. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I6eb723e165edf59973d83c66eace43acdce237de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-06-14 17:07:16 +00:00
_qt_internal_extend_sbom(${target} ${sbom_args})
CMake: Generate an SPDX v2.3 SBOM file for each built repository This change adds a new -sbom configure option to allow generating and installing an SPDX v2.3 SBOM file when building a qt repo. The -sbom-dir option can be used to configure the location where each repo sbom file will be installed. By default it is installed into $prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx which is basically ~/Qt/sbom/qtbase-6.8.0.spdx The file is installed as part of the default installation rules, but it can also be installed manually using the "sbom" installation component, or "sbom_$lower_project_name" in a top-level build. For example: cmake install . --component sbom_qtbase CMake 3.19+ is needed to read the qt_attribution.json files for copyrights, license info, etc. When using an older cmake version, configuration will error out. It is possible to opt into using an older cmake version, but the generated sbom will lack all the attribution file information. Using an older cmake version is untested and not officially supported. Implementation notes. The bulk of the implementation is split into 4 new files: - QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing and dispatching the generation of various pieces of the SBOM document e.g. a SDPX package associated with a target like Core, a SDPX file entry for each target binary file (per-config shared library, archive, executable, etc) - QtPublicSbomGenerationHelpers.cmake - for non-Qt specific implementation of SPDX generation. This also has some code that was taken from the cmake-sbom 3rd party project, so it is dual licensed under the usual Qt build system BSD license, as well as the MIT license of the 3rd party project - QtPublicGitHelpers.cmake - for git related features, mainly to embed queried hashes or tags into version strings, is dual-licensed for the same reasons as QtPublicSbomGenerationHelpers.cmake - QtSbomHelpers.cmake - Qt-specific functions that just forward arguments to the public functions. These are meant to be used in our Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones for naming consistency. These function would mostly be used to annotate 3rd party libraries with sbom info and to add sbom info for unusual target setups (like the Bootstrap library), because most of the handling is already done automatically via qt_internal_add_module/plugin/etc. The files are put into Public cmake files, with the future hope of making this available to user projects in some capacity. The distinction of Qt-specific and non-Qt specific code might blur a bit, and thus the separation across files might not always be consistent, but it was best effort. The main purpose of the code is to collect various information about targets and their relationships and generate equivalent SPDX info. Collection is currently done for the following targets: Qt modules, plugins, apps, tools, system libraries, bundled 3rd party libraries and partial 3rd party sources compiled directly as part of Qt targets. Each target has an equivalent SPDX package generated with information like version, license, copyright, CPE (common vulnerability identifier), files that belong to the package, and relationships on other SPDX packages (associated cmake targets), mostly gathered from direct linking dependencies. Each package might also contain files, e.g. libQt6Core.so for the Core target. Each file also has info like license id, copyrights, but also the list of source files that were used to generate the file and a sha1 checksum. SPDX documents can also refer to packages in other SPDX documents, and those are referred to via external document references. This is the case when building qtdeclarative and we refer to Core. For qt provided targets, we have complete information regarding licenses, and copyrights. For bundled 3rd party libraries, we should also have most information, which is usually parsed from the src/3rdparty/libfoo/qt_attribution.json files. If there are multiple attribution files, or if the files have multiple entries, we create a separate SBOM package for each of those entries, because each might have a separate copyright or version, and an sbom package can have only one version (although many copyrights). For system libraries we usually lack the information because we don't have attribution files for Find scripts. So the info needs to be manually annotated via arguments to the sbom function calls, or the FindFoo.cmake scripts expose that information in some form and we can query it. There are also corner cases like 3rdparty sources being directly included in a Qt library, like the m4dc files for Gui, or PCRE2 for Bootstrap. Or QtWebEngine libraries (either Qt bundled or Chromium bundled or system libraries) which get linked in by GN instead of CMake, so there are no direct targets for them. The information for these need to be annotated manually as well. There is also a distinction to be made for static Qt builds (or any static Qt library in a shared build), where the system libraries found during the Qt build might not be the same that are linked into the final user application or library. The actual generation of the SBOM is done by file(GENERATE)-ing one .cmake file for each target, file, external ref, etc, which will be included in a top-level cmake script. The top-level cmake script will run through each included file, to append to a "staging" spdx file, which will then be used in a configure_file() call to replace some final variables, like embedding a file checksum. There are install rules to generate a complete SBOM during installation, and an optional 'sbom' custom target that allows building an incomplete SBOM during the build step. The build target is just for convenience and faster development iteration time. It is incomplete because it is missing the installed file SHA1 checksums and the document verification code (the sha1 of all sha1s). We can't compute those during the build before the files are actually installed. A complete SBOM can only be achieved at installation time. The install script will include all the generated helper files, but also set some additional variables to ensure checksumming happens, and also handle multi-config installation, among other small things. For multi-config builds, CMake doesn't offer a way to run code after all configs are installed, because they might not always be installed, someone might choose to install just Release. To handle that, we rely on ninja installing each config sequentially (because ninja places the install rules into the 'console' pool which runs one task at a time). For each installed config we create a config-specific marker file. Once all marker files are present, whichever config ends up being installed as the last one, we run the sbom generation once, and then delete all marker files. There are a few internal variables that can be set during configuration to enable various checks (and other features) on the generated spdx files: - QT_INTERNAL_SBOM_VERIFY - QT_INTERNAL_SBOM_AUDIT - QT_INTERNAL_SBOM_AUDIT_NO_ERROR - QT_INTERNAL_SBOM_GENERATE_JSON - QT_INTERNAL_SBOM_SHOW_TABLE - QT_INTERNAL_SBOM_DEFAULT_CHECKS These use 3rd party python tools, so they are not enabled by default. If enabled, they run at installation time after the sbom is installed. We will hopefully enable them in CI. Overall, the code is still a bit messy in a few places, due to time constraints, but can be improved later. Some possible TODOs for the future: - Do we need to handle 3rd party libs linked into a Qt static library in a Qt shared build, where the Qt static lib is not installed, but linked into a Qt shared library, somehow specially? We can record a package for it, but we can't create a spdx file record for it (and associated source relationships) because we don't install the file, and spdx requires the file to be installed and checksummed. Perhaps we can consider adding some free-form text snippet to the package itself? - Do we want to add parsing of .cpp source files for Copyrights, to embed them into the packages? This will likely slow down configuration quite a bit. - Currently sbom info attached to WrapFoo packages in one repo is not exported / available in other repos. E.g. If we annotate WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be available when looking up WrapZLIB in qtimageformats. This is because they are IMPORTED libraries, and are not exported. We might want to record this info in the future. [ChangeLog][Build System] A new -sbom configure option can be used to generate and install a SPDX SBOM (Software Bill of Materials) file for each built Qt repository. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 17:02:56 +00:00
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
set(target_private "${target}Private")
Add missing PRIVATE_MODULE_INTERFACEs to INTERNAL_MODULEs To detect the internal module ouside the qt_internal_add_module function need to mark it with the property. This adds _qt_is_internal_module property to the Qt internal modules. Since PRIVATE_MODULE_INTERFACE only was applicable to pure Private modules, INTERNAL_MODULEs is missing those dependencies if they were specified. Add extra condition to qt_internal_extend_target to link PRIVATE_MODULE_INTERFACE libraries to internal modules as well. Pick-to: 6.2 6.1 Change-Id: I9c32fa5bad3aff365f5d7663349e5365d5f1d72d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-24 11:30:51 +00:00
get_target_property(is_internal_module ${target} _qt_is_internal_module)
# Internal modules don't have Private targets but we still need to
# propagate their private dependencies.
if(is_internal_module)
set(target_private "${target}")
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(TARGET "${target_private}")
CMake: Warn when PRIVATE_MODULE_INTERFACE is provided with no target Warn if the PRIVATE_MODULE_INTERFACE option is provided a value, but there is no ${target}Private target to set the interface dependencies on. Pick-to: 6.2 Task-number: QTBUG-95921 Change-Id: I7d4df9cb3aa9b7746d836b82019ecdd9c8f50fdc Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-23 18:47:05 +00:00
target_link_libraries("${target_private}"
INTERFACE ${arg_PRIVATE_MODULE_INTERFACE})
CMake: Only load Qt6FooPrivate automatically when building Qt [ChangeLog][CMake] CMake packages of public Qt modules don't provide the targets of their private counterparts anymore. User projects must now call find_package(Qt6 COMPONENTS FooPrivate) to make use of the Qt6::FooPrivate target. User projects that rely on the old behavior can set the CMake variable QT_FIND_PRIVATE_MODULES to ON. For user projects, the warning message we know from QMake is displayed. The warning can be disabled by setting the CMake variable QT_NO_PRIVATE_MODULE_WARNING to ON. Within Qt itself, find_package(Qt6Foo) will still find_package(Qt6FooPrivate). For static Qt builds, we need to wrap usage of private Qt modules in $<BUILD_INTERFACE> or $<BUILD_LOCAL_INTERFACE> (if CMake's version is >= 3.26). Static builds with CMake < 3.26 will always load the private modules if the Qt6FooConfig.cmake from Qt's build tree is loaded. This is the case in non-prefix builds and (in the future) when building examples as external project. This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-03 16:19:22 +00:00
qt_internal_register_target_dependencies("${target_private}"
PUBLIC ${arg_PRIVATE_MODULE_INTERFACE}
)
CMake: Warn when PRIVATE_MODULE_INTERFACE is provided with no target Warn if the PRIVATE_MODULE_INTERFACE option is provided a value, but there is no ${target}Private target to set the interface dependencies on. Pick-to: 6.2 Task-number: QTBUG-95921 Change-Id: I7d4df9cb3aa9b7746d836b82019ecdd9c8f50fdc Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-23 18:47:05 +00:00
elseif(arg_PRIVATE_MODULE_INTERFACE)
set(warning_message "")
string(APPEND warning_message
"The PRIVATE_MODULE_INTERFACE option was provided the values:"
"'${arg_PRIVATE_MODULE_INTERFACE}' "
"but there is no ${target}Private target to assign them to."
"Ensure the target exists or remove the option.")
message(AUTHOR_WARNING "${warning_message}")
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()
Replace qt_record_extra_qt_package_dependency with qt_register_target_dependencies qt_register_target_dependencies does the same thing as qt_record_extra_qt_package_dependency but in more convenient way. Update the qt_register_target_dependencies signature and adjust naming, it now accepts PUBLIC and PRIVATE multi-value arguments and called qt_internal_register_target_dependencies. Use it and deprecate qt_record_extra_qt_package_dependency. Pick-to: 6.5 6.8 6.9 Change-Id: I0594cf699ec1e3af7210dd7450fa3f81c1f565ae Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-07 16:51:30 +00:00
set(qt_register_target_dependencies_args "")
CMake: Only load Qt6FooPrivate automatically when building Qt [ChangeLog][CMake] CMake packages of public Qt modules don't provide the targets of their private counterparts anymore. User projects must now call find_package(Qt6 COMPONENTS FooPrivate) to make use of the Qt6::FooPrivate target. User projects that rely on the old behavior can set the CMake variable QT_FIND_PRIVATE_MODULES to ON. For user projects, the warning message we know from QMake is displayed. The warning can be disabled by setting the CMake variable QT_NO_PRIVATE_MODULE_WARNING to ON. Within Qt itself, find_package(Qt6Foo) will still find_package(Qt6FooPrivate). For static Qt builds, we need to wrap usage of private Qt modules in $<BUILD_INTERFACE> or $<BUILD_LOCAL_INTERFACE> (if CMake's version is >= 3.26). Static builds with CMake < 3.26 will always load the private modules if the Qt6FooConfig.cmake from Qt's build tree is loaded. This is the case in non-prefix builds and (in the future) when building examples as external project. This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-03 16:19:22 +00:00
if(arg_PUBLIC_LIBRARIES)
Replace qt_record_extra_qt_package_dependency with qt_register_target_dependencies qt_register_target_dependencies does the same thing as qt_record_extra_qt_package_dependency but in more convenient way. Update the qt_register_target_dependencies signature and adjust naming, it now accepts PUBLIC and PRIVATE multi-value arguments and called qt_internal_register_target_dependencies. Use it and deprecate qt_record_extra_qt_package_dependency. Pick-to: 6.5 6.8 6.9 Change-Id: I0594cf699ec1e3af7210dd7450fa3f81c1f565ae Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-07 16:51:30 +00:00
list(APPEND qt_register_target_dependencies_args
CMake: Only load Qt6FooPrivate automatically when building Qt [ChangeLog][CMake] CMake packages of public Qt modules don't provide the targets of their private counterparts anymore. User projects must now call find_package(Qt6 COMPONENTS FooPrivate) to make use of the Qt6::FooPrivate target. User projects that rely on the old behavior can set the CMake variable QT_FIND_PRIVATE_MODULES to ON. For user projects, the warning message we know from QMake is displayed. The warning can be disabled by setting the CMake variable QT_NO_PRIVATE_MODULE_WARNING to ON. Within Qt itself, find_package(Qt6Foo) will still find_package(Qt6FooPrivate). For static Qt builds, we need to wrap usage of private Qt modules in $<BUILD_INTERFACE> or $<BUILD_LOCAL_INTERFACE> (if CMake's version is >= 3.26). Static builds with CMake < 3.26 will always load the private modules if the Qt6FooConfig.cmake from Qt's build tree is loaded. This is the case in non-prefix builds and (in the future) when building examples as external project. This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-03 16:19:22 +00:00
PUBLIC ${arg_PUBLIC_LIBRARIES})
Replace qt_record_extra_qt_package_dependency with qt_register_target_dependencies qt_register_target_dependencies does the same thing as qt_record_extra_qt_package_dependency but in more convenient way. Update the qt_register_target_dependencies signature and adjust naming, it now accepts PUBLIC and PRIVATE multi-value arguments and called qt_internal_register_target_dependencies. Use it and deprecate qt_record_extra_qt_package_dependency. Pick-to: 6.5 6.8 6.9 Change-Id: I0594cf699ec1e3af7210dd7450fa3f81c1f565ae Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-07 16:51:30 +00:00
endif()
if(qt_libs_private OR arg_LIBRARIES)
list(APPEND qt_register_target_dependencies_args
PRIVATE ${qt_libs_private} ${arg_LIBRARIES})
endif()
qt_internal_register_target_dependencies("${target}"
${qt_register_target_dependencies_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
qt_autogen_tools(${target}
ENABLE_AUTOGEN_TOOLS ${arg_ENABLE_AUTOGEN_TOOLS}
DISABLE_AUTOGEN_TOOLS ${arg_DISABLE_AUTOGEN_TOOLS})
qt_update_precompiled_header("${target}" "${arg_PRECOMPILED_HEADER}")
Improve the internal handling of unity build - Removed the NO_UNITY_BUILD argument from commands that disable it by default. - Add a warning in case NO_UNITY_BUILD or NO_UNITY_BUILD_SOURCES is being used where it is already disabled, e.g., qt_internal_add_test - Exclude all sources of a target from unity build if NO_UNITY_BUILD is set on the target. This sounds a bit harsh, but I have noticed that sometimes the same source file can be included somewhere else, and some unexpected collision may occur. - qt_examples_build_end excludes all its examples from the unity build. - qt_build_test now sets the CMAKE_UNITY_BUILD to OFF before configuring the tests, and restore its value when done. Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: Ia42e7dd5a5bfb151db241deb639325720fd91eec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-09 13:53:14 +00:00
## Also exclude them from 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
qt_update_ignore_pch_source("${target}" "${arg_NO_PCH_SOURCES}")
## Ignore objective-c files for PCH (not supported atm)
qt_ignore_pch_obj_c_sources("${target}" "${arg_SOURCES}")
Improve the internal handling of unity build - Removed the NO_UNITY_BUILD argument from commands that disable it by default. - Add a warning in case NO_UNITY_BUILD or NO_UNITY_BUILD_SOURCES is being used where it is already disabled, e.g., qt_internal_add_test - Exclude all sources of a target from unity build if NO_UNITY_BUILD is set on the target. This sounds a bit harsh, but I have noticed that sometimes the same source file can be included somewhere else, and some unexpected collision may occur. - qt_examples_build_end excludes all its examples from the unity build. - qt_build_test now sets the CMAKE_UNITY_BUILD to OFF before configuring the tests, and restore its value when done. Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: Ia42e7dd5a5bfb151db241deb639325720fd91eec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-09 13:53:14 +00:00
if(arg_NO_UNITY_BUILD)
set_target_properties("${target}" PROPERTIES UNITY_BUILD OFF)
qt_update_ignore_unity_build_sources("${target}" "${arg_SOURCES}")
endif()
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
if(arg_NO_UNITY_BUILD_SOURCES)
qt_update_ignore_unity_build_sources("${target}" "${arg_NO_UNITY_BUILD_SOURCES}")
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
else()
if(QT_CMAKE_DEBUG_EXTEND_TARGET)
message("qt_extend_target(${target} CONDITION ${arg_CONDITION} ...): Skipped")
endif()
endif()
Add CONDITION_INDEPENDENT_SOURCES argument to qt_internal_extend_target The argument allows to ignore the condition for source files if they are used in the Qt code without corresponding guards. The header files of this kind usually have internal guards, that suppress the error at the location where they are used, so AUTOGEN is skipped for these header files to suppress the warnings from CMake. If file belongs to a module, it will display AUTHOR_WARNING which should urge Qt maintainers to guard the use of the source file properly. Task-number: QTBUG-103196 Change-Id: I7b4c12031a5d19ff15868d4782c0d396ef7aed8c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2022-11-03 15:38:51 +00:00
if(arg_CONDITION_INDEPENDENT_SOURCES)
set_source_files_properties(${arg_CONDITION_INDEPENDENT_SOURCES} PROPERTIES
_qt_extend_target_condition "${arg_CONDITION}"
SKIP_AUTOGEN TRUE
)
qt_internal_get_target_sources_property(sources_property)
set_property(TARGET ${target} APPEND PROPERTY
${sources_property} "${arg_CONDITION_INDEPENDENT_SOURCES}")
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
CMake: prefix elf to linker script keywords/properties The linker script properties/keywords are only used for elf targets, so we rename them to make the code more expressive. Pick-to: 6.10 Change-Id: I94cf843c78bb8d9650807e3b9584b1b983c3cf47 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-08-12 05:50:55 +00:00
if(arg_EXTRA_ELF_LINKER_SCRIPT_CONTENT)
CMake: Fix linkage with lld 16.0 lld 16.0 is more picky about symbol versioning than previous versions (and other linkers such as ld.bfd, gold or mold). It now errors out if a symbol is versioned but not defined (see 8796677de8900dc154aef45f8620c3f987a40291). Outside of detecting support for symbol versioning (fixed by 462832), this causes linking Qt6 libraries other than Qt6Core to fail because their linker scripts try to add versioning to qt_version_tag, which is defined in Qt6Core rather than the library being linked. The obvious (and working) fix is to version qt_version_tag only where it is defined (Qt6Core), but this is not what the original intent seems to be. Task-number: QTBUG-111514 Change-Id: I963d417befb0f6b2260c57f059eeda1fe79200c9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-02-25 18:10:06 +00:00
set_target_properties(${target} PROPERTIES
CMake: prefix elf to linker script keywords/properties The linker script properties/keywords are only used for elf targets, so we rename them to make the code more expressive. Pick-to: 6.10 Change-Id: I94cf843c78bb8d9650807e3b9584b1b983c3cf47 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-08-12 05:50:55 +00:00
_qt_extra_elf_linker_script_content "${arg_EXTRA_ELF_LINKER_SCRIPT_CONTENT}")
CMake: Fix linkage with lld 16.0 lld 16.0 is more picky about symbol versioning than previous versions (and other linkers such as ld.bfd, gold or mold). It now errors out if a symbol is versioned but not defined (see 8796677de8900dc154aef45f8620c3f987a40291). Outside of detecting support for symbol versioning (fixed by 462832), this causes linking Qt6 libraries other than Qt6Core to fail because their linker scripts try to add versioning to qt_version_tag, which is defined in Qt6Core rather than the library being linked. The obvious (and working) fix is to version qt_version_tag only where it is defined (Qt6Core), but this is not what the original intent seems to be. Task-number: QTBUG-111514 Change-Id: I963d417befb0f6b2260c57f059eeda1fe79200c9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-02-25 18:10:06 +00:00
endif()
CMake: prefix elf to linker script keywords/properties The linker script properties/keywords are only used for elf targets, so we rename them to make the code more expressive. Pick-to: 6.10 Change-Id: I94cf843c78bb8d9650807e3b9584b1b983c3cf47 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-08-12 05:50:55 +00:00
if(arg_EXTRA_ELF_LINKER_SCRIPT_EXPORTS)
Remove Qt_6_PRIVATE_API ELF version from a symbol used by QFuture::then() QFuture::then() uses QtPrivate::Continuation::create(), which in turn uses private API from an inline function: f->d.setContinuation(ContinuationWrapper(std::move(continuation)), fi.d); f->d is QFutureInterfaceBase (a public class), but its setContinuation() takes QFutureInterfaceBasePrivate by pointer. Our ELF versioning scripts mark everything that uses that class as private, resulting in: 4806: 0000000000287d70 365 FUNC GLOBAL PROTECTED 16 _ZN20QFutureInterfaceBase15setContinuationESt8functionIFvRKS_EEP27QFutureInterfaceBasePrivate@@Qt_6_PRIVATE_API This commit adds an exception for this symbol, causing it to go back to the regular "Qt_6" ELF version: 5629: 00000000003d6a16 366 FUNC GLOBAL PROTECTED 16 _ZN20QFutureInterfaceBase15setContinuationESt8functionIFvRKS_EEP27QFutureInterfaceBasePrivate@@Qt_6 This solution can probably be cleaned up a bit by moving the marker into the header files parsed by syncqt, so they follow code motion without having to remember to update the CMakeLists.txt. That requires some surgery with syncqt, so not suitable for cherry-picking. As a drive-by, fix the target_type check for the _qt_extra_linker_script_content genex property Fixes: QTBUG-117514 Pick-to: 6.6 Change-Id: I85599ea5ca7a4b79a8bbfffd178b92e73dbe11de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-10-06 16:53:26 +00:00
set_target_properties(${target} PROPERTIES
CMake: prefix elf to linker script keywords/properties The linker script properties/keywords are only used for elf targets, so we rename them to make the code more expressive. Pick-to: 6.10 Change-Id: I94cf843c78bb8d9650807e3b9584b1b983c3cf47 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-08-12 05:50:55 +00:00
_qt_extra_elf_linker_script_exports "${arg_EXTRA_ELF_LINKER_SCRIPT_EXPORTS}")
Remove Qt_6_PRIVATE_API ELF version from a symbol used by QFuture::then() QFuture::then() uses QtPrivate::Continuation::create(), which in turn uses private API from an inline function: f->d.setContinuation(ContinuationWrapper(std::move(continuation)), fi.d); f->d is QFutureInterfaceBase (a public class), but its setContinuation() takes QFutureInterfaceBasePrivate by pointer. Our ELF versioning scripts mark everything that uses that class as private, resulting in: 4806: 0000000000287d70 365 FUNC GLOBAL PROTECTED 16 _ZN20QFutureInterfaceBase15setContinuationESt8functionIFvRKS_EEP27QFutureInterfaceBasePrivate@@Qt_6_PRIVATE_API This commit adds an exception for this symbol, causing it to go back to the regular "Qt_6" ELF version: 5629: 00000000003d6a16 366 FUNC GLOBAL PROTECTED 16 _ZN20QFutureInterfaceBase15setContinuationESt8functionIFvRKS_EEP27QFutureInterfaceBasePrivate@@Qt_6 This solution can probably be cleaned up a bit by moving the marker into the header files parsed by syncqt, so they follow code motion without having to remember to update the CMakeLists.txt. That requires some surgery with syncqt, so not suitable for cherry-picking. As a drive-by, fix the target_type check for the _qt_extra_linker_script_content genex property Fixes: QTBUG-117514 Pick-to: 6.6 Change-Id: I85599ea5ca7a4b79a8bbfffd178b92e73dbe11de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-10-06 16:53:26 +00:00
endif()
CMake: support reduced relocations for namespaced Qt The dynlist files passed to the linker have hardcoded function names that do not take namespacing into account. We therefore generate the dynlist files at configure time from the qt namespace. Task-number: QTBUG-138543 Pick-to: 6.10 Change-Id: Ib3521b83942548cb09c11687e1701c2308f9d148 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-08-07 02:12:26 +00:00
if(arg_ELF_LINKER_DYNAMIC_LIST)
qt_internal_apply_dynamic_list_linker_flags(${target} "${arg_ELF_LINKER_DYNAMIC_LIST}")
endif()
Fix the static linking of plugins to the Qt tools and internal executables Qt tools and executables may required the static plugins from modules that are build as part of the Qt build tree. In this case we need to force plugin importing. This adds the qt_internal_import_plugins call when we extend the executable target. Replace the previos solution that considered libraries that were provided in the arguments of the qt_internal_add_executable call only. Pick-to: 6.7 6.6 6.5 Fixes: QTBUG-111988 Change-Id: Ifa2cf7f1f68d9f90cafc64f225aebe11d4cdb2ae Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-03-27 17:55:40 +00:00
if(is_executable)
Consider the qt_internal_extend_target calls when adding deps on qpa_default_plugins Applications not necessarly link QtGui module in qt_internal_add_executable. They still may add link it in followoup qt_internal_extend_target calls. We should consider this when adding dependencies on qpa_default_plugins to the internal executables. Pick-to: 6.7 Change-Id: Icc413bd35b631b3a356e4033faab4e6c01b29a60 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-03-28 10:03:25 +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.
set(linked_libs ${arg_PUBLIC_LIBRARIES} ${arg_LIBRARIES})
if(linked_libs MATCHES "(^|;)(${QT_CMAKE_EXPORT_NAMESPACE}::|Qt::)?Gui($|;)" AND
TARGET qpa_default_plugins)
add_dependencies("${target}" qpa_default_plugins)
endif()
# For executables collect static plugins that these targets depend on.
qt_internal_import_plugins(${target} ${linked_libs})
Fix the static linking of plugins to the Qt tools and internal executables Qt tools and executables may required the static plugins from modules that are build as part of the Qt build tree. In this case we need to force plugin importing. This adds the qt_internal_import_plugins call when we extend the executable target. Replace the previos solution that considered libraries that were provided in the arguments of the qt_internal_add_executable call only. Pick-to: 6.7 6.6 6.5 Fixes: QTBUG-111988 Change-Id: Ifa2cf7f1f68d9f90cafc64f225aebe11d4cdb2ae Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-03-27 17:55:40 +00:00
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endfunction()
CMake: Only load Qt6FooPrivate automatically when building Qt [ChangeLog][CMake] CMake packages of public Qt modules don't provide the targets of their private counterparts anymore. User projects must now call find_package(Qt6 COMPONENTS FooPrivate) to make use of the Qt6::FooPrivate target. User projects that rely on the old behavior can set the CMake variable QT_FIND_PRIVATE_MODULES to ON. For user projects, the warning message we know from QMake is displayed. The warning can be disabled by setting the CMake variable QT_NO_PRIVATE_MODULE_WARNING to ON. Within Qt itself, find_package(Qt6Foo) will still find_package(Qt6FooPrivate). For static Qt builds, we need to wrap usage of private Qt modules in $<BUILD_INTERFACE> or $<BUILD_LOCAL_INTERFACE> (if CMake's version is >= 3.26). Static builds with CMake < 3.26 will always load the private modules if the Qt6FooConfig.cmake from Qt's build tree is loaded. This is the case in non-prefix builds and (in the future) when building examples as external project. This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-03 16:19:22 +00:00
# Takes an output variable and a list of libraries.
#
# Every library that is a private module is wrapped in $<BUILD_INTERFACE> or
# $<BUILD_LOCAL_INTERFACE> if CMake is new enough.
#
# This is necessary for static builds, because if Qt6Foo links to Qt6BarPrivate, this link
# dependency is purely internal. If we don't do this, CMake adds a target check for Qt6BarPrivate
# in Qt6FooTargets.cmake. This breaks if Qt6BarPrivate is not find_package'ed before.
function(qt_internal_wrap_private_modules out_var)
set(result "")
if(CMAKE_VERSION VERSION_LESS "3.26")
set(wrapper_genex "BUILD_INTERFACE")
else()
set(wrapper_genex "BUILD_LOCAL_INTERFACE")
endif()
foreach(lib IN LISTS ARGN)
if(TARGET "${lib}")
get_target_property(lib_is_private_module ${lib} _qt_is_private_module)
if(lib_is_private_module)
# Add the public module as non-wrapped link dependency. This is necessary for
# targets that link only to the private module. Consumers of this target would then
# get a linker error about missing symbols from that Qt module.
get_target_property(lib_public_module_target ${lib} _qt_public_module_target_name)
list(APPEND result "${INSTALL_CMAKE_NAMESPACE}::${lib_public_module_target}")
# Wrap the private module in BUILD_LOCAL_INTERFACE.
set(lib "$<${wrapper_genex}:${lib}>")
endif()
endif()
list(APPEND result "${lib}")
endforeach()
set("${out_var}" "${result}" PARENT_SCOPE)
endfunction()
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
# Given CMAKE_CONFIG and ALL_CMAKE_CONFIGS, determines if a directory suffix needs to be appended
# to each destination, and sets the computed install target destination arguments in OUT_VAR.
# Defaults used for each of the destination types, and can be configured per destination type.
function(qt_get_install_target_default_args)
cmake_parse_arguments(PARSE_ARGV 0 arg
""
CMake: Generate an SPDX v2.3 SBOM file for each built repository This change adds a new -sbom configure option to allow generating and installing an SPDX v2.3 SBOM file when building a qt repo. The -sbom-dir option can be used to configure the location where each repo sbom file will be installed. By default it is installed into $prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx which is basically ~/Qt/sbom/qtbase-6.8.0.spdx The file is installed as part of the default installation rules, but it can also be installed manually using the "sbom" installation component, or "sbom_$lower_project_name" in a top-level build. For example: cmake install . --component sbom_qtbase CMake 3.19+ is needed to read the qt_attribution.json files for copyrights, license info, etc. When using an older cmake version, configuration will error out. It is possible to opt into using an older cmake version, but the generated sbom will lack all the attribution file information. Using an older cmake version is untested and not officially supported. Implementation notes. The bulk of the implementation is split into 4 new files: - QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing and dispatching the generation of various pieces of the SBOM document e.g. a SDPX package associated with a target like Core, a SDPX file entry for each target binary file (per-config shared library, archive, executable, etc) - QtPublicSbomGenerationHelpers.cmake - for non-Qt specific implementation of SPDX generation. This also has some code that was taken from the cmake-sbom 3rd party project, so it is dual licensed under the usual Qt build system BSD license, as well as the MIT license of the 3rd party project - QtPublicGitHelpers.cmake - for git related features, mainly to embed queried hashes or tags into version strings, is dual-licensed for the same reasons as QtPublicSbomGenerationHelpers.cmake - QtSbomHelpers.cmake - Qt-specific functions that just forward arguments to the public functions. These are meant to be used in our Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones for naming consistency. These function would mostly be used to annotate 3rd party libraries with sbom info and to add sbom info for unusual target setups (like the Bootstrap library), because most of the handling is already done automatically via qt_internal_add_module/plugin/etc. The files are put into Public cmake files, with the future hope of making this available to user projects in some capacity. The distinction of Qt-specific and non-Qt specific code might blur a bit, and thus the separation across files might not always be consistent, but it was best effort. The main purpose of the code is to collect various information about targets and their relationships and generate equivalent SPDX info. Collection is currently done for the following targets: Qt modules, plugins, apps, tools, system libraries, bundled 3rd party libraries and partial 3rd party sources compiled directly as part of Qt targets. Each target has an equivalent SPDX package generated with information like version, license, copyright, CPE (common vulnerability identifier), files that belong to the package, and relationships on other SPDX packages (associated cmake targets), mostly gathered from direct linking dependencies. Each package might also contain files, e.g. libQt6Core.so for the Core target. Each file also has info like license id, copyrights, but also the list of source files that were used to generate the file and a sha1 checksum. SPDX documents can also refer to packages in other SPDX documents, and those are referred to via external document references. This is the case when building qtdeclarative and we refer to Core. For qt provided targets, we have complete information regarding licenses, and copyrights. For bundled 3rd party libraries, we should also have most information, which is usually parsed from the src/3rdparty/libfoo/qt_attribution.json files. If there are multiple attribution files, or if the files have multiple entries, we create a separate SBOM package for each of those entries, because each might have a separate copyright or version, and an sbom package can have only one version (although many copyrights). For system libraries we usually lack the information because we don't have attribution files for Find scripts. So the info needs to be manually annotated via arguments to the sbom function calls, or the FindFoo.cmake scripts expose that information in some form and we can query it. There are also corner cases like 3rdparty sources being directly included in a Qt library, like the m4dc files for Gui, or PCRE2 for Bootstrap. Or QtWebEngine libraries (either Qt bundled or Chromium bundled or system libraries) which get linked in by GN instead of CMake, so there are no direct targets for them. The information for these need to be annotated manually as well. There is also a distinction to be made for static Qt builds (or any static Qt library in a shared build), where the system libraries found during the Qt build might not be the same that are linked into the final user application or library. The actual generation of the SBOM is done by file(GENERATE)-ing one .cmake file for each target, file, external ref, etc, which will be included in a top-level cmake script. The top-level cmake script will run through each included file, to append to a "staging" spdx file, which will then be used in a configure_file() call to replace some final variables, like embedding a file checksum. There are install rules to generate a complete SBOM during installation, and an optional 'sbom' custom target that allows building an incomplete SBOM during the build step. The build target is just for convenience and faster development iteration time. It is incomplete because it is missing the installed file SHA1 checksums and the document verification code (the sha1 of all sha1s). We can't compute those during the build before the files are actually installed. A complete SBOM can only be achieved at installation time. The install script will include all the generated helper files, but also set some additional variables to ensure checksumming happens, and also handle multi-config installation, among other small things. For multi-config builds, CMake doesn't offer a way to run code after all configs are installed, because they might not always be installed, someone might choose to install just Release. To handle that, we rely on ninja installing each config sequentially (because ninja places the install rules into the 'console' pool which runs one task at a time). For each installed config we create a config-specific marker file. Once all marker files are present, whichever config ends up being installed as the last one, we run the sbom generation once, and then delete all marker files. There are a few internal variables that can be set during configuration to enable various checks (and other features) on the generated spdx files: - QT_INTERNAL_SBOM_VERIFY - QT_INTERNAL_SBOM_AUDIT - QT_INTERNAL_SBOM_AUDIT_NO_ERROR - QT_INTERNAL_SBOM_GENERATE_JSON - QT_INTERNAL_SBOM_SHOW_TABLE - QT_INTERNAL_SBOM_DEFAULT_CHECKS These use 3rd party python tools, so they are not enabled by default. If enabled, they run at installation time after the sbom is installed. We will hopefully enable them in CI. Overall, the code is still a bit messy in a few places, due to time constraints, but can be improved later. Some possible TODOs for the future: - Do we need to handle 3rd party libs linked into a Qt static library in a Qt shared build, where the Qt static lib is not installed, but linked into a Qt shared library, somehow specially? We can record a package for it, but we can't create a spdx file record for it (and associated source relationships) because we don't install the file, and spdx requires the file to be installed and checksummed. Perhaps we can consider adding some free-form text snippet to the package itself? - Do we want to add parsing of .cpp source files for Copyrights, to embed them into the packages? This will likely slow down configuration quite a bit. - Currently sbom info attached to WrapFoo packages in one repo is not exported / available in other repos. E.g. If we annotate WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be available when looking up WrapZLIB in qtimageformats. This is because they are IMPORTED libraries, and are not exported. We might want to record this info in the future. [ChangeLog][Build System] A new -sbom configure option can be used to generate and install a SPDX SBOM (Software Bill of Materials) file for each built Qt repository. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 17:02:56 +00:00
"OUT_VAR;OUT_VAR_RUNTIME;CMAKE_CONFIG;RUNTIME;LIBRARY;ARCHIVE;INCLUDES;BUNDLE"
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
"ALL_CMAKE_CONFIGS")
_qt_internal_validate_all_args_are_parsed(arg)
if(NOT arg_CMAKE_CONFIG)
message(FATAL_ERROR "No value given for CMAKE_CONFIG.")
endif()
if(NOT arg_ALL_CMAKE_CONFIGS)
message(FATAL_ERROR "No value given for ALL_CMAKE_CONFIGS.")
endif()
list(LENGTH arg_ALL_CMAKE_CONFIGS all_configs_count)
list(GET arg_ALL_CMAKE_CONFIGS 0 first_config)
set(suffix "")
if(all_configs_count GREATER 1 AND NOT arg_CMAKE_CONFIG STREQUAL first_config)
set(suffix "/${arg_CMAKE_CONFIG}")
endif()
set(runtime "${INSTALL_BINDIR}")
if(arg_RUNTIME)
set(runtime "${arg_RUNTIME}")
endif()
set(library "${INSTALL_LIBDIR}")
if(arg_LIBRARY)
set(library "${arg_LIBRARY}")
endif()
set(archive "${INSTALL_LIBDIR}")
if(arg_ARCHIVE)
set(archive "${arg_ARCHIVE}")
endif()
set(includes "${INSTALL_INCLUDEDIR}")
if(arg_INCLUDES)
set(includes "${arg_INCLUDES}")
endif()
set(bundle "${INSTALL_BINDIR}")
if(arg_BUNDLE)
set(bundle "${arg_BUNDLE}")
endif()
set(args
RUNTIME DESTINATION "${runtime}${suffix}"
LIBRARY DESTINATION "${library}${suffix}"
ARCHIVE DESTINATION "${archive}${suffix}" COMPONENT Devel
BUNDLE DESTINATION "${bundle}${suffix}"
INCLUDES DESTINATION "${includes}${suffix}")
set(${arg_OUT_VAR} "${args}" PARENT_SCOPE)
CMake: Generate an SPDX v2.3 SBOM file for each built repository This change adds a new -sbom configure option to allow generating and installing an SPDX v2.3 SBOM file when building a qt repo. The -sbom-dir option can be used to configure the location where each repo sbom file will be installed. By default it is installed into $prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx which is basically ~/Qt/sbom/qtbase-6.8.0.spdx The file is installed as part of the default installation rules, but it can also be installed manually using the "sbom" installation component, or "sbom_$lower_project_name" in a top-level build. For example: cmake install . --component sbom_qtbase CMake 3.19+ is needed to read the qt_attribution.json files for copyrights, license info, etc. When using an older cmake version, configuration will error out. It is possible to opt into using an older cmake version, but the generated sbom will lack all the attribution file information. Using an older cmake version is untested and not officially supported. Implementation notes. The bulk of the implementation is split into 4 new files: - QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing and dispatching the generation of various pieces of the SBOM document e.g. a SDPX package associated with a target like Core, a SDPX file entry for each target binary file (per-config shared library, archive, executable, etc) - QtPublicSbomGenerationHelpers.cmake - for non-Qt specific implementation of SPDX generation. This also has some code that was taken from the cmake-sbom 3rd party project, so it is dual licensed under the usual Qt build system BSD license, as well as the MIT license of the 3rd party project - QtPublicGitHelpers.cmake - for git related features, mainly to embed queried hashes or tags into version strings, is dual-licensed for the same reasons as QtPublicSbomGenerationHelpers.cmake - QtSbomHelpers.cmake - Qt-specific functions that just forward arguments to the public functions. These are meant to be used in our Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones for naming consistency. These function would mostly be used to annotate 3rd party libraries with sbom info and to add sbom info for unusual target setups (like the Bootstrap library), because most of the handling is already done automatically via qt_internal_add_module/plugin/etc. The files are put into Public cmake files, with the future hope of making this available to user projects in some capacity. The distinction of Qt-specific and non-Qt specific code might blur a bit, and thus the separation across files might not always be consistent, but it was best effort. The main purpose of the code is to collect various information about targets and their relationships and generate equivalent SPDX info. Collection is currently done for the following targets: Qt modules, plugins, apps, tools, system libraries, bundled 3rd party libraries and partial 3rd party sources compiled directly as part of Qt targets. Each target has an equivalent SPDX package generated with information like version, license, copyright, CPE (common vulnerability identifier), files that belong to the package, and relationships on other SPDX packages (associated cmake targets), mostly gathered from direct linking dependencies. Each package might also contain files, e.g. libQt6Core.so for the Core target. Each file also has info like license id, copyrights, but also the list of source files that were used to generate the file and a sha1 checksum. SPDX documents can also refer to packages in other SPDX documents, and those are referred to via external document references. This is the case when building qtdeclarative and we refer to Core. For qt provided targets, we have complete information regarding licenses, and copyrights. For bundled 3rd party libraries, we should also have most information, which is usually parsed from the src/3rdparty/libfoo/qt_attribution.json files. If there are multiple attribution files, or if the files have multiple entries, we create a separate SBOM package for each of those entries, because each might have a separate copyright or version, and an sbom package can have only one version (although many copyrights). For system libraries we usually lack the information because we don't have attribution files for Find scripts. So the info needs to be manually annotated via arguments to the sbom function calls, or the FindFoo.cmake scripts expose that information in some form and we can query it. There are also corner cases like 3rdparty sources being directly included in a Qt library, like the m4dc files for Gui, or PCRE2 for Bootstrap. Or QtWebEngine libraries (either Qt bundled or Chromium bundled or system libraries) which get linked in by GN instead of CMake, so there are no direct targets for them. The information for these need to be annotated manually as well. There is also a distinction to be made for static Qt builds (or any static Qt library in a shared build), where the system libraries found during the Qt build might not be the same that are linked into the final user application or library. The actual generation of the SBOM is done by file(GENERATE)-ing one .cmake file for each target, file, external ref, etc, which will be included in a top-level cmake script. The top-level cmake script will run through each included file, to append to a "staging" spdx file, which will then be used in a configure_file() call to replace some final variables, like embedding a file checksum. There are install rules to generate a complete SBOM during installation, and an optional 'sbom' custom target that allows building an incomplete SBOM during the build step. The build target is just for convenience and faster development iteration time. It is incomplete because it is missing the installed file SHA1 checksums and the document verification code (the sha1 of all sha1s). We can't compute those during the build before the files are actually installed. A complete SBOM can only be achieved at installation time. The install script will include all the generated helper files, but also set some additional variables to ensure checksumming happens, and also handle multi-config installation, among other small things. For multi-config builds, CMake doesn't offer a way to run code after all configs are installed, because they might not always be installed, someone might choose to install just Release. To handle that, we rely on ninja installing each config sequentially (because ninja places the install rules into the 'console' pool which runs one task at a time). For each installed config we create a config-specific marker file. Once all marker files are present, whichever config ends up being installed as the last one, we run the sbom generation once, and then delete all marker files. There are a few internal variables that can be set during configuration to enable various checks (and other features) on the generated spdx files: - QT_INTERNAL_SBOM_VERIFY - QT_INTERNAL_SBOM_AUDIT - QT_INTERNAL_SBOM_AUDIT_NO_ERROR - QT_INTERNAL_SBOM_GENERATE_JSON - QT_INTERNAL_SBOM_SHOW_TABLE - QT_INTERNAL_SBOM_DEFAULT_CHECKS These use 3rd party python tools, so they are not enabled by default. If enabled, they run at installation time after the sbom is installed. We will hopefully enable them in CI. Overall, the code is still a bit messy in a few places, due to time constraints, but can be improved later. Some possible TODOs for the future: - Do we need to handle 3rd party libs linked into a Qt static library in a Qt shared build, where the Qt static lib is not installed, but linked into a Qt shared library, somehow specially? We can record a package for it, but we can't create a spdx file record for it (and associated source relationships) because we don't install the file, and spdx requires the file to be installed and checksummed. Perhaps we can consider adding some free-form text snippet to the package itself? - Do we want to add parsing of .cpp source files for Copyrights, to embed them into the packages? This will likely slow down configuration quite a bit. - Currently sbom info attached to WrapFoo packages in one repo is not exported / available in other repos. E.g. If we annotate WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be available when looking up WrapZLIB in qtimageformats. This is because they are IMPORTED libraries, and are not exported. We might want to record this info in the future. [ChangeLog][Build System] A new -sbom configure option can be used to generate and install a SPDX SBOM (Software Bill of Materials) file for each built Qt repository. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 17:02:56 +00:00
if(arg_OUT_VAR_RUNTIME)
set(args
"${runtime}${suffix}"
)
set(${arg_OUT_VAR_RUNTIME} "${args}" PARENT_SCOPE)
endif()
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
endfunction()
macro(qt_internal_setup_default_target_function_options)
set(__default_private_args
SOURCES
LIBRARIES
INCLUDE_DIRECTORIES
SYSTEM_INCLUDE_DIRECTORIES
DEFINES
DBUS_ADAPTOR_BASENAME
DBUS_ADAPTOR_FLAGS
DBUS_ADAPTOR_SOURCES
DBUS_INTERFACE_BASENAME
DBUS_INTERFACE_FLAGS
DBUS_INTERFACE_SOURCES
FEATURE_DEPENDENCIES
COMPILE_OPTIONS
LINK_OPTIONS
MOC_OPTIONS
DISABLE_AUTOGEN_TOOLS
ENABLE_AUTOGEN_TOOLS
PLUGIN_TYPES
NO_PCH_SOURCES
NO_UNITY_BUILD_SOURCES
)
set(__default_public_args
PUBLIC_LIBRARIES
PUBLIC_INCLUDE_DIRECTORIES
PUBLIC_DEFINES
PUBLIC_COMPILE_OPTIONS
PUBLIC_LINK_OPTIONS
)
set(__default_private_module_args
PRIVATE_MODULE_INTERFACE
)
set(__default_target_info_args
TARGET_VERSION
TARGET_PRODUCT
TARGET_DESCRIPTION
TARGET_COMPANY
TARGET_COPYRIGHT
)
CMake: Allow specifying most SBOM options to qt_internal_add_foo Previously, only a very short subset of options related to attribution files could be specified to qt_internal_add_module / qt_internal_extend_target. It is more convenient to allow specifying most (safe) options, instead of calling another function. Unsafe are considered paths like INSTALL_PATH and derivatives, TYPE which is too generic, and some other ones like LIBRARIES which would be duplicated, and causes warnings in cmake_parse_arguments if duplicated. Change the code to allow specifying most SBOM options and forwarding them to _qt_internal_extend_sbom. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I6eb723e165edf59973d83c66eace43acdce237de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-06-14 17:07:16 +00:00
_qt_internal_get_sbom_add_target_common_options(
__qt_internal_sbom_optional_args
__qt_internal_sbom_single_args
__qt_internal_sbom_multi_args
CMake: Generate an SPDX v2.3 SBOM file for each built repository This change adds a new -sbom configure option to allow generating and installing an SPDX v2.3 SBOM file when building a qt repo. The -sbom-dir option can be used to configure the location where each repo sbom file will be installed. By default it is installed into $prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx which is basically ~/Qt/sbom/qtbase-6.8.0.spdx The file is installed as part of the default installation rules, but it can also be installed manually using the "sbom" installation component, or "sbom_$lower_project_name" in a top-level build. For example: cmake install . --component sbom_qtbase CMake 3.19+ is needed to read the qt_attribution.json files for copyrights, license info, etc. When using an older cmake version, configuration will error out. It is possible to opt into using an older cmake version, but the generated sbom will lack all the attribution file information. Using an older cmake version is untested and not officially supported. Implementation notes. The bulk of the implementation is split into 4 new files: - QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing and dispatching the generation of various pieces of the SBOM document e.g. a SDPX package associated with a target like Core, a SDPX file entry for each target binary file (per-config shared library, archive, executable, etc) - QtPublicSbomGenerationHelpers.cmake - for non-Qt specific implementation of SPDX generation. This also has some code that was taken from the cmake-sbom 3rd party project, so it is dual licensed under the usual Qt build system BSD license, as well as the MIT license of the 3rd party project - QtPublicGitHelpers.cmake - for git related features, mainly to embed queried hashes or tags into version strings, is dual-licensed for the same reasons as QtPublicSbomGenerationHelpers.cmake - QtSbomHelpers.cmake - Qt-specific functions that just forward arguments to the public functions. These are meant to be used in our Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones for naming consistency. These function would mostly be used to annotate 3rd party libraries with sbom info and to add sbom info for unusual target setups (like the Bootstrap library), because most of the handling is already done automatically via qt_internal_add_module/plugin/etc. The files are put into Public cmake files, with the future hope of making this available to user projects in some capacity. The distinction of Qt-specific and non-Qt specific code might blur a bit, and thus the separation across files might not always be consistent, but it was best effort. The main purpose of the code is to collect various information about targets and their relationships and generate equivalent SPDX info. Collection is currently done for the following targets: Qt modules, plugins, apps, tools, system libraries, bundled 3rd party libraries and partial 3rd party sources compiled directly as part of Qt targets. Each target has an equivalent SPDX package generated with information like version, license, copyright, CPE (common vulnerability identifier), files that belong to the package, and relationships on other SPDX packages (associated cmake targets), mostly gathered from direct linking dependencies. Each package might also contain files, e.g. libQt6Core.so for the Core target. Each file also has info like license id, copyrights, but also the list of source files that were used to generate the file and a sha1 checksum. SPDX documents can also refer to packages in other SPDX documents, and those are referred to via external document references. This is the case when building qtdeclarative and we refer to Core. For qt provided targets, we have complete information regarding licenses, and copyrights. For bundled 3rd party libraries, we should also have most information, which is usually parsed from the src/3rdparty/libfoo/qt_attribution.json files. If there are multiple attribution files, or if the files have multiple entries, we create a separate SBOM package for each of those entries, because each might have a separate copyright or version, and an sbom package can have only one version (although many copyrights). For system libraries we usually lack the information because we don't have attribution files for Find scripts. So the info needs to be manually annotated via arguments to the sbom function calls, or the FindFoo.cmake scripts expose that information in some form and we can query it. There are also corner cases like 3rdparty sources being directly included in a Qt library, like the m4dc files for Gui, or PCRE2 for Bootstrap. Or QtWebEngine libraries (either Qt bundled or Chromium bundled or system libraries) which get linked in by GN instead of CMake, so there are no direct targets for them. The information for these need to be annotated manually as well. There is also a distinction to be made for static Qt builds (or any static Qt library in a shared build), where the system libraries found during the Qt build might not be the same that are linked into the final user application or library. The actual generation of the SBOM is done by file(GENERATE)-ing one .cmake file for each target, file, external ref, etc, which will be included in a top-level cmake script. The top-level cmake script will run through each included file, to append to a "staging" spdx file, which will then be used in a configure_file() call to replace some final variables, like embedding a file checksum. There are install rules to generate a complete SBOM during installation, and an optional 'sbom' custom target that allows building an incomplete SBOM during the build step. The build target is just for convenience and faster development iteration time. It is incomplete because it is missing the installed file SHA1 checksums and the document verification code (the sha1 of all sha1s). We can't compute those during the build before the files are actually installed. A complete SBOM can only be achieved at installation time. The install script will include all the generated helper files, but also set some additional variables to ensure checksumming happens, and also handle multi-config installation, among other small things. For multi-config builds, CMake doesn't offer a way to run code after all configs are installed, because they might not always be installed, someone might choose to install just Release. To handle that, we rely on ninja installing each config sequentially (because ninja places the install rules into the 'console' pool which runs one task at a time). For each installed config we create a config-specific marker file. Once all marker files are present, whichever config ends up being installed as the last one, we run the sbom generation once, and then delete all marker files. There are a few internal variables that can be set during configuration to enable various checks (and other features) on the generated spdx files: - QT_INTERNAL_SBOM_VERIFY - QT_INTERNAL_SBOM_AUDIT - QT_INTERNAL_SBOM_AUDIT_NO_ERROR - QT_INTERNAL_SBOM_GENERATE_JSON - QT_INTERNAL_SBOM_SHOW_TABLE - QT_INTERNAL_SBOM_DEFAULT_CHECKS These use 3rd party python tools, so they are not enabled by default. If enabled, they run at installation time after the sbom is installed. We will hopefully enable them in CI. Overall, the code is still a bit messy in a few places, due to time constraints, but can be improved later. Some possible TODOs for the future: - Do we need to handle 3rd party libs linked into a Qt static library in a Qt shared build, where the Qt static lib is not installed, but linked into a Qt shared library, somehow specially? We can record a package for it, but we can't create a spdx file record for it (and associated source relationships) because we don't install the file, and spdx requires the file to be installed and checksummed. Perhaps we can consider adding some free-form text snippet to the package itself? - Do we want to add parsing of .cpp source files for Copyrights, to embed them into the packages? This will likely slow down configuration quite a bit. - Currently sbom info attached to WrapFoo packages in one repo is not exported / available in other repos. E.g. If we annotate WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be available when looking up WrapZLIB in qtimageformats. This is because they are IMPORTED libraries, and are not exported. We might want to record this info in the future. [ChangeLog][Build System] A new -sbom configure option can be used to generate and install a SPDX SBOM (Software Bill of Materials) file for each built Qt repository. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 17:02:56 +00:00
)
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
# Collection of arguments so they can be shared across qt_internal_add_executable
# and qt_internal_add_test_helper.
set(__qt_internal_add_executable_optional_args
GUI
NO_INSTALL
EXCEPTIONS
DELAY_RC
DELAY_TARGET_INFO
QT_APP
CMake:Android: add wrapper scripts to easily run apps Create a script that allows running an app or a test easily similar to running on host. This improves development workflow and time by allowing quick runs without having to manually call the various adb commands to launch, get a pid of the app and then print the logcat, let alone passing parameters or environment variables. For normal apps, the app package name is retrieved by the script, run and live logcat is printed as long as the app is still running. For tests, the script calls androidtestrunner, allowing test parameters to be passed to the test. For CI debugging, this would save quite a lot of hussle and frustration trying to run or debug a test app. One other benefit for this is enabling running Android tests from Qt Creator's testlib plugin without big changes to Qt Creator to support androidtestrunner explicitly. Because file(GENERATE) would fail if called twice for the same file, I use file(WRITE). This is used because at the time of calling the target executable finalizer, we don't know if the target is a test or not, so we rely on writing the script first as a normal target, then call it if the target is a test where it overrides the script. For this also, parameters passed to the runner or androidtestrunner can't handle generator expressions. [ChangeLog][CMake][Android] Add wrapper scripts to run Android apps and tests with ease from the host. Task-number: QTBUG-129889 Change-Id: I84e85ce2bbf6944c8aa20bdc2c2b6d7b956bc748 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-10-07 14:43:31 +00:00
QT_TEST
QT_MANUAL_TEST
CMake: Mark benchmark executables with a property This will be used in a follow up patch to identify them. Pick-to: 6.8 Task-number: QTBUG-93625 Task-number: QTBUG-112212 Change-Id: I39d5eb9f79ac67af0808efeda4d7f4e0a6908cc9 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-10-23 15:19:00 +00:00
QT_BENCHMARK_TEST
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
NO_UNITY_BUILD
CMake: Allow specifying most SBOM options to qt_internal_add_foo Previously, only a very short subset of options related to attribution files could be specified to qt_internal_add_module / qt_internal_extend_target. It is more convenient to allow specifying most (safe) options, instead of calling another function. Unsafe are considered paths like INSTALL_PATH and derivatives, TYPE which is too generic, and some other ones like LIBRARIES which would be duplicated, and causes warnings in cmake_parse_arguments if duplicated. Change the code to allow specifying most SBOM options and forwarding them to _qt_internal_extend_sbom. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I6eb723e165edf59973d83c66eace43acdce237de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-06-14 17:07:16 +00:00
${__qt_internal_sbom_optional_args}
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
)
set(__qt_internal_add_executable_single_args
CORE_LIBRARY
OUTPUT_DIRECTORY
INSTALL_DIRECTORY
VERSION
${__default_target_info_args}
CMake: Generate an SPDX v2.3 SBOM file for each built repository This change adds a new -sbom configure option to allow generating and installing an SPDX v2.3 SBOM file when building a qt repo. The -sbom-dir option can be used to configure the location where each repo sbom file will be installed. By default it is installed into $prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx which is basically ~/Qt/sbom/qtbase-6.8.0.spdx The file is installed as part of the default installation rules, but it can also be installed manually using the "sbom" installation component, or "sbom_$lower_project_name" in a top-level build. For example: cmake install . --component sbom_qtbase CMake 3.19+ is needed to read the qt_attribution.json files for copyrights, license info, etc. When using an older cmake version, configuration will error out. It is possible to opt into using an older cmake version, but the generated sbom will lack all the attribution file information. Using an older cmake version is untested and not officially supported. Implementation notes. The bulk of the implementation is split into 4 new files: - QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing and dispatching the generation of various pieces of the SBOM document e.g. a SDPX package associated with a target like Core, a SDPX file entry for each target binary file (per-config shared library, archive, executable, etc) - QtPublicSbomGenerationHelpers.cmake - for non-Qt specific implementation of SPDX generation. This also has some code that was taken from the cmake-sbom 3rd party project, so it is dual licensed under the usual Qt build system BSD license, as well as the MIT license of the 3rd party project - QtPublicGitHelpers.cmake - for git related features, mainly to embed queried hashes or tags into version strings, is dual-licensed for the same reasons as QtPublicSbomGenerationHelpers.cmake - QtSbomHelpers.cmake - Qt-specific functions that just forward arguments to the public functions. These are meant to be used in our Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones for naming consistency. These function would mostly be used to annotate 3rd party libraries with sbom info and to add sbom info for unusual target setups (like the Bootstrap library), because most of the handling is already done automatically via qt_internal_add_module/plugin/etc. The files are put into Public cmake files, with the future hope of making this available to user projects in some capacity. The distinction of Qt-specific and non-Qt specific code might blur a bit, and thus the separation across files might not always be consistent, but it was best effort. The main purpose of the code is to collect various information about targets and their relationships and generate equivalent SPDX info. Collection is currently done for the following targets: Qt modules, plugins, apps, tools, system libraries, bundled 3rd party libraries and partial 3rd party sources compiled directly as part of Qt targets. Each target has an equivalent SPDX package generated with information like version, license, copyright, CPE (common vulnerability identifier), files that belong to the package, and relationships on other SPDX packages (associated cmake targets), mostly gathered from direct linking dependencies. Each package might also contain files, e.g. libQt6Core.so for the Core target. Each file also has info like license id, copyrights, but also the list of source files that were used to generate the file and a sha1 checksum. SPDX documents can also refer to packages in other SPDX documents, and those are referred to via external document references. This is the case when building qtdeclarative and we refer to Core. For qt provided targets, we have complete information regarding licenses, and copyrights. For bundled 3rd party libraries, we should also have most information, which is usually parsed from the src/3rdparty/libfoo/qt_attribution.json files. If there are multiple attribution files, or if the files have multiple entries, we create a separate SBOM package for each of those entries, because each might have a separate copyright or version, and an sbom package can have only one version (although many copyrights). For system libraries we usually lack the information because we don't have attribution files for Find scripts. So the info needs to be manually annotated via arguments to the sbom function calls, or the FindFoo.cmake scripts expose that information in some form and we can query it. There are also corner cases like 3rdparty sources being directly included in a Qt library, like the m4dc files for Gui, or PCRE2 for Bootstrap. Or QtWebEngine libraries (either Qt bundled or Chromium bundled or system libraries) which get linked in by GN instead of CMake, so there are no direct targets for them. The information for these need to be annotated manually as well. There is also a distinction to be made for static Qt builds (or any static Qt library in a shared build), where the system libraries found during the Qt build might not be the same that are linked into the final user application or library. The actual generation of the SBOM is done by file(GENERATE)-ing one .cmake file for each target, file, external ref, etc, which will be included in a top-level cmake script. The top-level cmake script will run through each included file, to append to a "staging" spdx file, which will then be used in a configure_file() call to replace some final variables, like embedding a file checksum. There are install rules to generate a complete SBOM during installation, and an optional 'sbom' custom target that allows building an incomplete SBOM during the build step. The build target is just for convenience and faster development iteration time. It is incomplete because it is missing the installed file SHA1 checksums and the document verification code (the sha1 of all sha1s). We can't compute those during the build before the files are actually installed. A complete SBOM can only be achieved at installation time. The install script will include all the generated helper files, but also set some additional variables to ensure checksumming happens, and also handle multi-config installation, among other small things. For multi-config builds, CMake doesn't offer a way to run code after all configs are installed, because they might not always be installed, someone might choose to install just Release. To handle that, we rely on ninja installing each config sequentially (because ninja places the install rules into the 'console' pool which runs one task at a time). For each installed config we create a config-specific marker file. Once all marker files are present, whichever config ends up being installed as the last one, we run the sbom generation once, and then delete all marker files. There are a few internal variables that can be set during configuration to enable various checks (and other features) on the generated spdx files: - QT_INTERNAL_SBOM_VERIFY - QT_INTERNAL_SBOM_AUDIT - QT_INTERNAL_SBOM_AUDIT_NO_ERROR - QT_INTERNAL_SBOM_GENERATE_JSON - QT_INTERNAL_SBOM_SHOW_TABLE - QT_INTERNAL_SBOM_DEFAULT_CHECKS These use 3rd party python tools, so they are not enabled by default. If enabled, they run at installation time after the sbom is installed. We will hopefully enable them in CI. Overall, the code is still a bit messy in a few places, due to time constraints, but can be improved later. Some possible TODOs for the future: - Do we need to handle 3rd party libs linked into a Qt static library in a Qt shared build, where the Qt static lib is not installed, but linked into a Qt shared library, somehow specially? We can record a package for it, but we can't create a spdx file record for it (and associated source relationships) because we don't install the file, and spdx requires the file to be installed and checksummed. Perhaps we can consider adding some free-form text snippet to the package itself? - Do we want to add parsing of .cpp source files for Copyrights, to embed them into the packages? This will likely slow down configuration quite a bit. - Currently sbom info attached to WrapFoo packages in one repo is not exported / available in other repos. E.g. If we annotate WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be available when looking up WrapZLIB in qtimageformats. This is because they are IMPORTED libraries, and are not exported. We might want to record this info in the future. [ChangeLog][Build System] A new -sbom configure option can be used to generate and install a SPDX SBOM (Software Bill of Materials) file for each built Qt repository. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 17:02:56 +00:00
${__qt_internal_sbom_single_args}
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
)
set(__qt_internal_add_executable_multi_args
${__default_private_args}
${__default_public_args}
CMake: Generate an SPDX v2.3 SBOM file for each built repository This change adds a new -sbom configure option to allow generating and installing an SPDX v2.3 SBOM file when building a qt repo. The -sbom-dir option can be used to configure the location where each repo sbom file will be installed. By default it is installed into $prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx which is basically ~/Qt/sbom/qtbase-6.8.0.spdx The file is installed as part of the default installation rules, but it can also be installed manually using the "sbom" installation component, or "sbom_$lower_project_name" in a top-level build. For example: cmake install . --component sbom_qtbase CMake 3.19+ is needed to read the qt_attribution.json files for copyrights, license info, etc. When using an older cmake version, configuration will error out. It is possible to opt into using an older cmake version, but the generated sbom will lack all the attribution file information. Using an older cmake version is untested and not officially supported. Implementation notes. The bulk of the implementation is split into 4 new files: - QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing and dispatching the generation of various pieces of the SBOM document e.g. a SDPX package associated with a target like Core, a SDPX file entry for each target binary file (per-config shared library, archive, executable, etc) - QtPublicSbomGenerationHelpers.cmake - for non-Qt specific implementation of SPDX generation. This also has some code that was taken from the cmake-sbom 3rd party project, so it is dual licensed under the usual Qt build system BSD license, as well as the MIT license of the 3rd party project - QtPublicGitHelpers.cmake - for git related features, mainly to embed queried hashes or tags into version strings, is dual-licensed for the same reasons as QtPublicSbomGenerationHelpers.cmake - QtSbomHelpers.cmake - Qt-specific functions that just forward arguments to the public functions. These are meant to be used in our Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones for naming consistency. These function would mostly be used to annotate 3rd party libraries with sbom info and to add sbom info for unusual target setups (like the Bootstrap library), because most of the handling is already done automatically via qt_internal_add_module/plugin/etc. The files are put into Public cmake files, with the future hope of making this available to user projects in some capacity. The distinction of Qt-specific and non-Qt specific code might blur a bit, and thus the separation across files might not always be consistent, but it was best effort. The main purpose of the code is to collect various information about targets and their relationships and generate equivalent SPDX info. Collection is currently done for the following targets: Qt modules, plugins, apps, tools, system libraries, bundled 3rd party libraries and partial 3rd party sources compiled directly as part of Qt targets. Each target has an equivalent SPDX package generated with information like version, license, copyright, CPE (common vulnerability identifier), files that belong to the package, and relationships on other SPDX packages (associated cmake targets), mostly gathered from direct linking dependencies. Each package might also contain files, e.g. libQt6Core.so for the Core target. Each file also has info like license id, copyrights, but also the list of source files that were used to generate the file and a sha1 checksum. SPDX documents can also refer to packages in other SPDX documents, and those are referred to via external document references. This is the case when building qtdeclarative and we refer to Core. For qt provided targets, we have complete information regarding licenses, and copyrights. For bundled 3rd party libraries, we should also have most information, which is usually parsed from the src/3rdparty/libfoo/qt_attribution.json files. If there are multiple attribution files, or if the files have multiple entries, we create a separate SBOM package for each of those entries, because each might have a separate copyright or version, and an sbom package can have only one version (although many copyrights). For system libraries we usually lack the information because we don't have attribution files for Find scripts. So the info needs to be manually annotated via arguments to the sbom function calls, or the FindFoo.cmake scripts expose that information in some form and we can query it. There are also corner cases like 3rdparty sources being directly included in a Qt library, like the m4dc files for Gui, or PCRE2 for Bootstrap. Or QtWebEngine libraries (either Qt bundled or Chromium bundled or system libraries) which get linked in by GN instead of CMake, so there are no direct targets for them. The information for these need to be annotated manually as well. There is also a distinction to be made for static Qt builds (or any static Qt library in a shared build), where the system libraries found during the Qt build might not be the same that are linked into the final user application or library. The actual generation of the SBOM is done by file(GENERATE)-ing one .cmake file for each target, file, external ref, etc, which will be included in a top-level cmake script. The top-level cmake script will run through each included file, to append to a "staging" spdx file, which will then be used in a configure_file() call to replace some final variables, like embedding a file checksum. There are install rules to generate a complete SBOM during installation, and an optional 'sbom' custom target that allows building an incomplete SBOM during the build step. The build target is just for convenience and faster development iteration time. It is incomplete because it is missing the installed file SHA1 checksums and the document verification code (the sha1 of all sha1s). We can't compute those during the build before the files are actually installed. A complete SBOM can only be achieved at installation time. The install script will include all the generated helper files, but also set some additional variables to ensure checksumming happens, and also handle multi-config installation, among other small things. For multi-config builds, CMake doesn't offer a way to run code after all configs are installed, because they might not always be installed, someone might choose to install just Release. To handle that, we rely on ninja installing each config sequentially (because ninja places the install rules into the 'console' pool which runs one task at a time). For each installed config we create a config-specific marker file. Once all marker files are present, whichever config ends up being installed as the last one, we run the sbom generation once, and then delete all marker files. There are a few internal variables that can be set during configuration to enable various checks (and other features) on the generated spdx files: - QT_INTERNAL_SBOM_VERIFY - QT_INTERNAL_SBOM_AUDIT - QT_INTERNAL_SBOM_AUDIT_NO_ERROR - QT_INTERNAL_SBOM_GENERATE_JSON - QT_INTERNAL_SBOM_SHOW_TABLE - QT_INTERNAL_SBOM_DEFAULT_CHECKS These use 3rd party python tools, so they are not enabled by default. If enabled, they run at installation time after the sbom is installed. We will hopefully enable them in CI. Overall, the code is still a bit messy in a few places, due to time constraints, but can be improved later. Some possible TODOs for the future: - Do we need to handle 3rd party libs linked into a Qt static library in a Qt shared build, where the Qt static lib is not installed, but linked into a Qt shared library, somehow specially? We can record a package for it, but we can't create a spdx file record for it (and associated source relationships) because we don't install the file, and spdx requires the file to be installed and checksummed. Perhaps we can consider adding some free-form text snippet to the package itself? - Do we want to add parsing of .cpp source files for Copyrights, to embed them into the packages? This will likely slow down configuration quite a bit. - Currently sbom info attached to WrapFoo packages in one repo is not exported / available in other repos. E.g. If we annotate WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be available when looking up WrapZLIB in qtimageformats. This is because they are IMPORTED libraries, and are not exported. We might want to record this info in the future. [ChangeLog][Build System] A new -sbom configure option can be used to generate and install a SPDX SBOM (Software Bill of Materials) file for each built Qt repository. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 17:02:56 +00:00
${__qt_internal_sbom_multi_args}
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
)
endmacro()
CMake: Split and refactor QtSetup.cmake Split all code in QtSetup into separate functions and macros, put them in more appropriate files, and call them in qt_internal_setup_build_and_global_variables. A new QtBuildOptionsHelpers.cmake is created which takes care of computing the default values of user-customizable options that are not pure configure features, like the cmake build type, whether to build tests / examples, whether to enable ccache, etc. The new function calls added in qt_internal_setup_build_and_global_variables try to preserve the previous code flow when QtBuild was included in-between the code that was run in QtSetup. Macros that have dependencies on various global variables were marked as such with inline comments for easier navigation and comprehension. After this change, QtSetup.cmake just includes QtBuild.cmake. We leave it to exist for easier git blaming, but new code should not be added to it unless really necessary. The intent is to merge a variant of this change to 6.6 and 6.5 as well. Task-number: QTBUG-86035 Change-Id: I3409c2d3ea8ee19a69104b12ab2692966ba5f9cf Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-11-16 16:10:01 +00:00
# Append a config-specific postfix to library names to ensure distinct names
# in a multi-config build.
# e.g. lib/libQt6DBus_relwithdebinfo.6.3.0.dylib
# Don't apply the postfix to the first encountered release-like config, so we have at least one
# config without a postifx.
# If postfixes are set by user warn about potential issues.
function(qt_internal_setup_cmake_config_postfix)
# Collect configuration that require postfix in Qt library names.
if(QT_GENERATOR_IS_MULTI_CONFIG)
set(postfix_configurations ${CMAKE_CONFIGURATION_TYPES})
else()
set(postfix_configurations ${CMAKE_BUILD_TYPE})
# Set the default postfix to empty by default for single-config builds.
string(TOLOWER "${CMAKE_BUILD_TYPE}" build_type_lower)
set(default_cmake_${build_type_lower}_postfix "")
endif()
# Override the generic debug postfixes above with custom debug postfixes (even in a single
# config build) to follow the conventions we had since Qt 5.
# e.g. lib/libQt6DBus_debug.6.3.0.dylib
if(WIN32)
if(MINGW)
# On MinGW we don't have "d" suffix for debug libraries like on Linux,
# unless we're building debug and release libraries in one go.
if(QT_GENERATOR_IS_MULTI_CONFIG)
set(default_cmake_debug_postfix "d")
endif()
else()
set(default_cmake_debug_postfix "d")
endif()
elseif(APPLE)
Apple: Don't `_debug`-suffix libraries in single config framework builds As part of fee15182949e88682131399c50b679be83a75385 we enabled framework debug builds, which left us with an inconsistent library naming. The framework libraries are always unsuffixed, e.g. QtGui.framework/QtGui, while we were adding _debug suffixes to the plugins and static libs. This was confusing macdeployqt, as it uses simple string matching logic for "_debug_" to detect that a Qt build is a debug build, and since the framework library didn't have a suffix it then failed to deploy the suffixed plugins. We now follow the requirement from the framework naming and skip the suffixing for all libraries in this configuration. Pick-to: 6.8 Change-Id: I982253fc46c65aa3fab52f8658f62ef63cdac49f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-06-20 10:48:26 +00:00
# Only add a suffix for explicit no-framework builds.
# For framework builds the library inside the framework
# is always unsuffixed, and we want to match that for
# plugins and other non-framework (static) libraries.
if(NOT (QT_FEATURE_framework OR FEATURE_framework
# Account for default in configure.json being ON
OR (NOT DEFINED QT_FEATURE_framework AND NOT DEFINED FEATURE_framework)))
set(default_cmake_debug_postfix "_debug")
endif()
CMake: Split and refactor QtSetup.cmake Split all code in QtSetup into separate functions and macros, put them in more appropriate files, and call them in qt_internal_setup_build_and_global_variables. A new QtBuildOptionsHelpers.cmake is created which takes care of computing the default values of user-customizable options that are not pure configure features, like the cmake build type, whether to build tests / examples, whether to enable ccache, etc. The new function calls added in qt_internal_setup_build_and_global_variables try to preserve the previous code flow when QtBuild was included in-between the code that was run in QtSetup. Macros that have dependencies on various global variables were marked as such with inline comments for easier navigation and comprehension. After this change, QtSetup.cmake just includes QtBuild.cmake. We leave it to exist for easier git blaming, but new code should not be added to it unless really necessary. The intent is to merge a variant of this change to 6.6 and 6.5 as well. Task-number: QTBUG-86035 Change-Id: I3409c2d3ea8ee19a69104b12ab2692966ba5f9cf Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-11-16 16:10:01 +00:00
endif()
set(custom_postfix_vars "")
set(release_configs Release RelWithDebInfo MinSizeRel)
set(found_first_release_config FALSE)
foreach(config_type IN LISTS postfix_configurations)
string(TOLOWER "${config_type}" config_type_lower)
string(TOUPPER "${config_type}" config_type_upper)
set(postfix_var CMAKE_${config_type_upper}_POSTFIX)
# Skip assigning postfix for the first release-like config.
if(NOT found_first_release_config
AND config_type IN_LIST release_configs)
set(found_first_release_config TRUE)
if(NOT "${${postfix_var}}" STREQUAL "")
list(APPEND custom_postfix_vars ${postfix_var})
endif()
continue()
endif()
# Check if the default postfix is set, use '_<config_type_lower>' otherwise.
set(default_postfix_var
default_cmake_${config_type_lower}_postfix)
if(NOT DEFINED ${default_postfix_var})
set(${default_postfix_var}
"_${config_type_lower}")
endif()
# If postfix is set by user avoid changing it, but save postfix variable that has
# a non-default value for further warning.
if("${${postfix_var}}" STREQUAL "")
CMake: Fix DEBUG_POSTFIX to apply to macOS multi-config builds There was refactoring in 8c41125118768ce037698e0605755128b2da705d to handle custom postfixes, which caused a regression in the postfix not being set for macOS frameworks. Specifically we set CMAKE_FRAMEWORK_MULTI_CONFIG_POSTFIX_DEBUG to the value of ${${postfix_var}} but that variable was empty, because we only set it in the PARENT_SCOPE. Set the variable also in the current scope. Amends 8c41125118768ce037698e0605755128b2da705d Pick-to: 6.5 6.7 Change-Id: Iae3f1050bb11805b4cce01ec491a13a3d6c0a9fc Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-05-21 15:15:04 +00:00
set(${postfix_var} "${${default_postfix_var}}")
CMake: Split and refactor QtSetup.cmake Split all code in QtSetup into separate functions and macros, put them in more appropriate files, and call them in qt_internal_setup_build_and_global_variables. A new QtBuildOptionsHelpers.cmake is created which takes care of computing the default values of user-customizable options that are not pure configure features, like the cmake build type, whether to build tests / examples, whether to enable ccache, etc. The new function calls added in qt_internal_setup_build_and_global_variables try to preserve the previous code flow when QtBuild was included in-between the code that was run in QtSetup. Macros that have dependencies on various global variables were marked as such with inline comments for easier navigation and comprehension. After this change, QtSetup.cmake just includes QtBuild.cmake. We leave it to exist for easier git blaming, but new code should not be added to it unless really necessary. The intent is to merge a variant of this change to 6.6 and 6.5 as well. Task-number: QTBUG-86035 Change-Id: I3409c2d3ea8ee19a69104b12ab2692966ba5f9cf Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-11-16 16:10:01 +00:00
set(${postfix_var} "${${default_postfix_var}}" PARENT_SCOPE)
elseif(NOT "${${postfix_var}}" STREQUAL "${${default_postfix_var}}")
list(APPEND custom_postfix_vars ${postfix_var})
endif()
# Adjust framework postfixes accordingly
if(APPLE)
set(CMAKE_FRAMEWORK_MULTI_CONFIG_POSTFIX_${config_type_upper}
"${${postfix_var}}" PARENT_SCOPE)
endif()
endforeach()
if(custom_postfix_vars)
list(REMOVE_DUPLICATES custom_postfix_vars)
list(JOIN custom_postfix_vars ", " postfix_vars_string)
message(WARNING "You are using custom library postfixes: '${postfix_vars_string}' which are"
" considered experimental and are not officially supported by Qt."
" Expect unforeseen issues and user projects built with qmake to be broken."
)
endif()
endfunction()
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
function(qt_is_imported_target target out_var)
if(NOT TARGET "${target}")
set(target "${QT_CMAKE_EXPORT_NAMESPACE}::${target}")
endif()
if(NOT TARGET "${target}")
message(FATAL_ERROR "Invalid target given to qt_is_imported_target: ${target}")
endif()
get_target_property(is_imported "${target}" IMPORTED)
set(${out_var} "${is_imported}" PARENT_SCOPE)
endfunction()
# Add Qt::target and Qt6::target as aliases for the target
function(qt_internal_add_target_aliases target)
CMake: Refactor parts of qt_internal_walk_libs Refactor the function in preparation of processing rcc object files. Introduce 2 new functions to get and set values in the memoization dictionary used by qt_internal_walk_libs. Modify qt_internal_add_target_aliases to assign the alias names it creates as properties on the target. Extract these aliases when available to assign memoized values not only for the initial library name, but also for its aliases. When recursively calling qt_internal_walk_libs, make sure to provide a unique out_var name based on the outer target name, and not just lib_libs. Otherwise the out_var values would be polluted from previous recursion runs. Make sure to check for -NOTFOUND in if() checks so that we reuse memoized values that are the empty string. Change-Id: I8fd8e2b0ae14d0ba8f502bc5a764d6e01095001a Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 15:53:15 +00:00
set(versionless_alias "Qt::${target}")
set(versionfull_alias "Qt${PROJECT_VERSION_MAJOR}::${target}")
set_target_properties("${target}" PROPERTIES _qt_versionless_alias "${versionless_alias}")
set_target_properties("${target}" PROPERTIES _qt_versionfull_alias "${versionfull_alias}")
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
get_target_property(type "${target}" TYPE)
if (type STREQUAL EXECUTABLE)
CMake: Refactor parts of qt_internal_walk_libs Refactor the function in preparation of processing rcc object files. Introduce 2 new functions to get and set values in the memoization dictionary used by qt_internal_walk_libs. Modify qt_internal_add_target_aliases to assign the alias names it creates as properties on the target. Extract these aliases when available to assign memoized values not only for the initial library name, but also for its aliases. When recursively calling qt_internal_walk_libs, make sure to provide a unique out_var name based on the outer target name, and not just lib_libs. Otherwise the out_var values would be polluted from previous recursion runs. Make sure to check for -NOTFOUND in if() checks so that we reuse memoized values that are the empty string. Change-Id: I8fd8e2b0ae14d0ba8f502bc5a764d6e01095001a Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 15:53:15 +00:00
add_executable("${versionless_alias}" ALIAS "${target}")
add_executable("${versionfull_alias}" ALIAS "${target}")
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
else()
CMake: Refactor parts of qt_internal_walk_libs Refactor the function in preparation of processing rcc object files. Introduce 2 new functions to get and set values in the memoization dictionary used by qt_internal_walk_libs. Modify qt_internal_add_target_aliases to assign the alias names it creates as properties on the target. Extract these aliases when available to assign memoized values not only for the initial library name, but also for its aliases. When recursively calling qt_internal_walk_libs, make sure to provide a unique out_var name based on the outer target name, and not just lib_libs. Otherwise the out_var values would be polluted from previous recursion runs. Make sure to check for -NOTFOUND in if() checks so that we reuse memoized values that are the empty string. Change-Id: I8fd8e2b0ae14d0ba8f502bc5a764d6e01095001a Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 15:53:15 +00:00
add_library("${versionless_alias}" ALIAS "${target}")
add_library("${versionfull_alias}" ALIAS "${target}")
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()
endfunction()
function(qt_get_cmake_configurations out_var)
set(possible_configs "${CMAKE_BUILD_TYPE}")
if(CMAKE_CONFIGURATION_TYPES)
set(possible_configs "${CMAKE_CONFIGURATION_TYPES}")
endif()
set(${out_var} "${possible_configs}" PARENT_SCOPE)
endfunction()
function(qt_clone_property_for_configs target property configs)
get_target_property(value "${target}" "${property}")
foreach(config ${configs})
string(TOUPPER "${config}" upper_config)
set_property(TARGET "${target}" PROPERTY "${property}_${upper_config}" "${value}")
endforeach()
endfunction()
function(qt_handle_multi_config_output_dirs target)
qt_get_cmake_configurations(possible_configs)
qt_clone_property_for_configs(${target} LIBRARY_OUTPUT_DIRECTORY "${possible_configs}")
qt_clone_property_for_configs(${target} RUNTIME_OUTPUT_DIRECTORY "${possible_configs}")
qt_clone_property_for_configs(${target} ARCHIVE_OUTPUT_DIRECTORY "${possible_configs}")
endfunction()
# Set target properties that are the same for all modules, plugins, executables
# and 3rdparty libraries.
function(qt_set_common_target_properties target)
CMake: Implement configure -reduce-exports This option maps to FEATURE_reduce_exports. The feature is on by default, except for MSVC. The reduce_exports configure test is not used in the CMake build. The <LANG>_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN target properties are now explicitly initialized in the qt_set_common_target_properties function, because we don't have access to the feature in QtSetup.cmake where the CMAKE_<LANG>_VISIBILITY_PRESET variables were set before. Task-number: QTBUG-85373 Change-Id: I378453f0e0665731970016170302871e20ceb4e2 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-08-25 06:17:23 +00:00
if(QT_FEATURE_reduce_exports)
set_target_properties(${target} PROPERTIES
C_VISIBILITY_PRESET hidden
CXX_VISIBILITY_PRESET hidden
OBJC_VISIBILITY_PRESET hidden
OBJCXX_VISIBILITY_PRESET hidden
VISIBILITY_INLINES_HIDDEN 1)
endif()
CMake: Fix module separate build error when -DFEATURE_static_runtime=ON Build qtbase with -DFEATURE_static_runtime=ON, and then separately build another module, following build error occurs: error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease'. That's because all the sources in this module are compiled with 'MD'. When separately building a module except qtbase, FEATURE_static_runtime is not exist in cmake cache. So we should use QT_FEATURE_static_runtime instead of FEATURE_static_runtime in qt_set_common_target_properties. Additionally, adjust the indentation. Pick-to: 6.0 Change-Id: I2cf4737db9d3e8533570039a66c7d277d62a8d14 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-12-16 05:32:04 +00:00
qt_internal_set_compile_pdb_names("${target}")
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()
# Set common, informational target properties.
#
# On Windows, these properties are used to generate the version information resource.
function(qt_set_target_info_properties target)
cmake_parse_arguments(arg "" "${__default_target_info_args}" "" ${ARGN})
Replace STREQUAL cases with variable checks As I was investigating the NO_UNITY_BUILD_SOURCES issue, I realized that we don't need to pass these quoted, especially now that we have moved to `cmake_parse_arguments(PARSE_ARGV`, and we can check their existence just by checking the `arg_*`, and that should be sufficient. I also left a warning that we are aware of this. Pick-to: 6.5 Change-Id: I4d939e80dc4671ea3ae9dc61516279f69ba2c5a5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-29 09:40:49 +00:00
if(NOT arg_TARGET_VERSION)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
set(arg_TARGET_VERSION "${PROJECT_VERSION}.0")
endif()
Replace STREQUAL cases with variable checks As I was investigating the NO_UNITY_BUILD_SOURCES issue, I realized that we don't need to pass these quoted, especially now that we have moved to `cmake_parse_arguments(PARSE_ARGV`, and we can check their existence just by checking the `arg_*`, and that should be sufficient. I also left a warning that we are aware of this. Pick-to: 6.5 Change-Id: I4d939e80dc4671ea3ae9dc61516279f69ba2c5a5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-29 09:40:49 +00:00
if(NOT arg_TARGET_PRODUCT)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
set(arg_TARGET_PRODUCT "Qt6")
endif()
Replace STREQUAL cases with variable checks As I was investigating the NO_UNITY_BUILD_SOURCES issue, I realized that we don't need to pass these quoted, especially now that we have moved to `cmake_parse_arguments(PARSE_ARGV`, and we can check their existence just by checking the `arg_*`, and that should be sufficient. I also left a warning that we are aware of this. Pick-to: 6.5 Change-Id: I4d939e80dc4671ea3ae9dc61516279f69ba2c5a5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-29 09:40:49 +00:00
if(NOT arg_TARGET_DESCRIPTION)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
set(arg_TARGET_DESCRIPTION "C++ Application Development Framework")
endif()
Replace STREQUAL cases with variable checks As I was investigating the NO_UNITY_BUILD_SOURCES issue, I realized that we don't need to pass these quoted, especially now that we have moved to `cmake_parse_arguments(PARSE_ARGV`, and we can check their existence just by checking the `arg_*`, and that should be sufficient. I also left a warning that we are aware of this. Pick-to: 6.5 Change-Id: I4d939e80dc4671ea3ae9dc61516279f69ba2c5a5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-29 09:40:49 +00:00
if(NOT arg_TARGET_COMPANY)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
set(arg_TARGET_COMPANY "The Qt Company Ltd.")
endif()
Replace STREQUAL cases with variable checks As I was investigating the NO_UNITY_BUILD_SOURCES issue, I realized that we don't need to pass these quoted, especially now that we have moved to `cmake_parse_arguments(PARSE_ARGV`, and we can check their existence just by checking the `arg_*`, and that should be sufficient. I also left a warning that we are aware of this. Pick-to: 6.5 Change-Id: I4d939e80dc4671ea3ae9dc61516279f69ba2c5a5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-29 09:40:49 +00:00
if(NOT arg_TARGET_COPYRIGHT)
Centralize copyright information for Qt Maintain one central place - .cmake.conf - for information about Qt's copyright. Pick-to: 6.2 6.5 Change-Id: Ibcbce4313eba9660d459061b0ad00307e267b8f7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-14 12:31:39 +00:00
set(arg_TARGET_COPYRIGHT "${QT_COPYRIGHT}")
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_target_properties(${target} PROPERTIES
QT_TARGET_VERSION "${arg_TARGET_VERSION}"
QT_TARGET_COMPANY_NAME "${arg_TARGET_COMPANY}"
QT_TARGET_DESCRIPTION "${arg_TARGET_DESCRIPTION}"
QT_TARGET_COPYRIGHT "${arg_TARGET_COPYRIGHT}"
QT_TARGET_PRODUCT_NAME "${arg_TARGET_PRODUCT}")
endfunction()
# Uses the QT_DELAYED_TARGET_* property values to set the final QT_TARGET_* properties.
# Needed when doing executable finalization at the end of a subdirectory scope
# (aka scope finalization).
function(qt_internal_set_target_info_properties_from_delayed_properties target)
set(args "")
foreach(prop ${__default_target_info_args})
get_target_property(prop_value "${target}" "QT_DELAYED_${prop}")
list(APPEND args "${prop}" "${prop_value}")
endforeach()
qt_set_target_info_properties(${target} ${args})
endfunction()
# Updates the QT_DELAYED_ properties with values from the QT_ variants, in case if they were
# set in-between a qt_add_* call and before scope finalization.
function(qt_internal_update_delayed_target_info_properties target)
foreach(prop ${__default_target_info_args})
get_target_property(prop_value "${target}" "QT_${prop}")
get_target_property(delayed_prop_value ${target} "QT_DELAYED_${prop}")
set(final_value "${delayed_prop_value}")
if(prop_value)
set(final_value "${prop_value}")
endif()
set_target_properties(${target} PROPERTIES "QT_DELAYED_${prop}" "${final_value}")
endforeach()
endfunction()
function(qt_internal_check_directory_or_type name dir type default result_var)
if ("x${dir}" STREQUAL x)
if("x${type}" STREQUAL x)
CMake: Rename qt6_add_plugin TYPE option to PLUGIN_TYPE The intention is to remove TYPE as a keyword completely before 6.2.0 release, but in case if that's not possible due to the large amount of repositories and examples, just print a deprecation warning for now and handle both TYPE and PLUGIN_TYPE. Task-number: QTBUG-95170 Pick-to: 6.2 Change-Id: If0c18345483b9254b0fc21120229fcc2a2fbfbf5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-04 14:18:44 +00:00
message(FATAL_ERROR
"qt_internal_add_plugin called without setting either PLUGIN_TYPE or ${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()
set(${result_var} "${default}" PARENT_SCOPE)
else()
set(${result_var} "${dir}" PARENT_SCOPE)
endif()
endfunction()
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
macro(qt_internal_get_export_additional_targets_keywords option_args single_args multi_args)
set(${option_args}
)
set(${single_args}
EXPORT_NAME_PREFIX
)
set(${multi_args}
TARGETS
TARGET_EXPORT_NAMES
)
endmacro()
CMake: Fix additional target info files ...for QT_BUILD_TOOLS_WHEN_CROSSCOMPILING. qt_internal_export_additional_targets_file now gets two lists of target names when run from qt_export_tools: - TARGETS containing actually existing targets, and - TARGET_EXPORT_NAMES containing the target names as they appear in the additional target info file. Operations that require actual targets are run on the TARGETS, in the additional target info file only TARGET_EXPORT_NAMES are written. This distinction is required for the case where the host Qt lacks a tool that is built in the target Qt. Example: host Qt is built with DEVELOPER_BUILD=OFF, target Qt is built with DEVELOPER_BUILD=ON. Then the host Qt lacks qmljs, but it is built in the target Qt. TARGETS contains qmljs_native, and TARGET_EXPORT_NAMES contains qmljs. Fixes: QTBUG-87693 Change-Id: I615aed996bfcbe654274defcda8c1cb2cc4b7b4e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-10-15 15:11:16 +00:00
# Create a Qt*AdditionalTargetInfo.cmake file that is included by Qt*Config.cmake
# and sets IMPORTED_*_<CONFIG> properties on the exported targets.
#
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
# The file also makes the targets global if the QT_PROMOTE_TO_GLOBAL_TARGETS property is set in the
# consuming project.
CMake: Promote all targets to global within a scope when possible CMake 3.21 introduced a new IMPORTED_TARGETS directory property which we can use to promote all imported targets within a scope to be global. This would cover transitive non-Qt imported targets which the Qt build system does not know about and is thus a more complete solution compared to promoting only Qt targets. Run a finalizer at the end of the directory scope where find_package(Qt6) is called to promote all imported targets within that scope to global (when requested). The old promotion method is disabled when the CMake version is new enough. Pick-to: 6.2 Task-number: QTBUG-92878 Task-number: QTBUG-94528 Change-Id: I533a3bd4186eba652f878ddd72c76118c2fd8bae Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-11 07:54:47 +00:00
# When using a CMake version lower than 3.21, only the specified TARGETS are made global.
# E.g. transitive non-Qt 3rd party targets of the specified targets are not made global.
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
#
CMake: Fix additional target info files ...for QT_BUILD_TOOLS_WHEN_CROSSCOMPILING. qt_internal_export_additional_targets_file now gets two lists of target names when run from qt_export_tools: - TARGETS containing actually existing targets, and - TARGET_EXPORT_NAMES containing the target names as they appear in the additional target info file. Operations that require actual targets are run on the TARGETS, in the additional target info file only TARGET_EXPORT_NAMES are written. This distinction is required for the case where the host Qt lacks a tool that is built in the target Qt. Example: host Qt is built with DEVELOPER_BUILD=OFF, target Qt is built with DEVELOPER_BUILD=ON. Then the host Qt lacks qmljs, but it is built in the target Qt. TARGETS contains qmljs_native, and TARGET_EXPORT_NAMES contains qmljs. Fixes: QTBUG-87693 Change-Id: I615aed996bfcbe654274defcda8c1cb2cc4b7b4e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-10-15 15:11:16 +00:00
# EXPORT_NAME_PREFIX:
# The portion of the file name before AdditionalTargetInfo.cmake
# CONFIG_INSTALL_DIR:
# Installation location for the target info file
# TARGETS:
# The internal target names. Those must be actual targets.
# TARGET_EXPORT_NAMES:
# The target names how they appear in the QtXXXTargets.cmake files.
# The names get prefixed by ${QT_CMAKE_EXPORT_NAMESPACE}:: unless they already are.
# This argument may be empty, then the target export names are the same as the internal ones.
#
# TARGETS and TARGET_EXPORT_NAMES must contain exactly the same number of elements.
# Example: TARGETS = qmljs_native
# TARGET_EXPORT_NAMES = Qt6::qmljs
#
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
function(qt_internal_export_additional_targets_file)
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
qt_internal_get_export_additional_targets_keywords(option_args single_args multi_args)
cmake_parse_arguments(arg
"${option_args}"
"${single_args};CONFIG_INSTALL_DIR"
"${multi_args}"
${ARGN})
qt_internal_append_export_additional_targets()
set_property(GLOBAL APPEND PROPERTY _qt_export_additional_targets_ids "${id}")
set_property(GLOBAL APPEND
PROPERTY _qt_export_additional_targets_export_name_prefix_${id} "${arg_EXPORT_NAME_PREFIX}")
set_property(GLOBAL APPEND
PROPERTY _qt_export_additional_targets_config_install_dir_${id} "${arg_CONFIG_INSTALL_DIR}")
qt_add_list_file_finalizer(qt_internal_export_additional_targets_file_finalizer)
endfunction()
function(qt_internal_get_export_additional_targets_id export_name out_var)
string(MAKE_C_IDENTIFIER "${export_name}" id)
set(${out_var} "${id}" PARENT_SCOPE)
endfunction()
# Uses outer-scope variables to keep the implementation less verbose.
macro(qt_internal_append_export_additional_targets)
qt_internal_validate_export_additional_targets(
EXPORT_NAME_PREFIX "${arg_EXPORT_NAME_PREFIX}"
TARGETS ${arg_TARGETS}
TARGET_EXPORT_NAMES ${arg_TARGET_EXPORT_NAMES})
qt_internal_get_export_additional_targets_id("${arg_EXPORT_NAME_PREFIX}" id)
set_property(GLOBAL APPEND
PROPERTY _qt_export_additional_targets_${id} "${arg_TARGETS}")
set_property(GLOBAL APPEND
PROPERTY _qt_export_additional_target_export_names_${id} "${arg_TARGET_EXPORT_NAMES}")
endmacro()
# Can be called to add additional targets to the file after the initial setup call.
# Used for resources.
function(qt_internal_add_targets_to_additional_targets_export_file)
qt_internal_get_export_additional_targets_keywords(option_args single_args multi_args)
cmake_parse_arguments(arg
"${option_args}"
"${single_args}"
"${multi_args}"
${ARGN})
qt_internal_append_export_additional_targets()
endfunction()
function(qt_internal_validate_export_additional_targets)
qt_internal_get_export_additional_targets_keywords(option_args single_args multi_args)
cmake_parse_arguments(arg
"${option_args}"
"${single_args}"
"${multi_args}"
${ARGN})
if(NOT arg_EXPORT_NAME_PREFIX)
message(FATAL_ERROR "qt_internal_validate_export_additional_targets: "
"Missing EXPORT_NAME_PREFIX argument.")
endif()
CMake: Fix additional target info files ...for QT_BUILD_TOOLS_WHEN_CROSSCOMPILING. qt_internal_export_additional_targets_file now gets two lists of target names when run from qt_export_tools: - TARGETS containing actually existing targets, and - TARGET_EXPORT_NAMES containing the target names as they appear in the additional target info file. Operations that require actual targets are run on the TARGETS, in the additional target info file only TARGET_EXPORT_NAMES are written. This distinction is required for the case where the host Qt lacks a tool that is built in the target Qt. Example: host Qt is built with DEVELOPER_BUILD=OFF, target Qt is built with DEVELOPER_BUILD=ON. Then the host Qt lacks qmljs, but it is built in the target Qt. TARGETS contains qmljs_native, and TARGET_EXPORT_NAMES contains qmljs. Fixes: QTBUG-87693 Change-Id: I615aed996bfcbe654274defcda8c1cb2cc4b7b4e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-10-15 15:11:16 +00:00
list(LENGTH arg_TARGETS num_TARGETS)
list(LENGTH arg_TARGET_EXPORT_NAMES num_TARGET_EXPORT_NAMES)
if(num_TARGET_EXPORT_NAMES GREATER 0)
if(NOT num_TARGETS EQUAL num_TARGET_EXPORT_NAMES)
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
message(FATAL_ERROR "qt_internal_validate_export_additional_targets: "
CMake: Fix additional target info files ...for QT_BUILD_TOOLS_WHEN_CROSSCOMPILING. qt_internal_export_additional_targets_file now gets two lists of target names when run from qt_export_tools: - TARGETS containing actually existing targets, and - TARGET_EXPORT_NAMES containing the target names as they appear in the additional target info file. Operations that require actual targets are run on the TARGETS, in the additional target info file only TARGET_EXPORT_NAMES are written. This distinction is required for the case where the host Qt lacks a tool that is built in the target Qt. Example: host Qt is built with DEVELOPER_BUILD=OFF, target Qt is built with DEVELOPER_BUILD=ON. Then the host Qt lacks qmljs, but it is built in the target Qt. TARGETS contains qmljs_native, and TARGET_EXPORT_NAMES contains qmljs. Fixes: QTBUG-87693 Change-Id: I615aed996bfcbe654274defcda8c1cb2cc4b7b4e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-10-15 15:11:16 +00:00
"TARGET_EXPORT_NAMES is set but has ${num_TARGET_EXPORT_NAMES} elements while "
"TARGETS has ${num_TARGETS} elements. "
"They must contain the same number of elements.")
endif()
else()
set(arg_TARGET_EXPORT_NAMES ${arg_TARGETS})
endif()
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
set(arg_TARGETS "${arg_TARGETS}" PARENT_SCOPE)
set(arg_TARGET_EXPORT_NAMES "${arg_TARGET_EXPORT_NAMES}" PARENT_SCOPE)
endfunction()
# The finalizer might be called multiple times in the same scope, but only the first one will
# process all the ids.
function(qt_internal_export_additional_targets_file_finalizer)
get_property(ids GLOBAL PROPERTY _qt_export_additional_targets_ids)
foreach(id ${ids})
qt_internal_export_additional_targets_file_handler("${id}")
endforeach()
set_property(GLOBAL PROPERTY _qt_export_additional_targets_ids "")
endfunction()
function(qt_internal_export_additional_targets_file_handler id)
get_property(arg_EXPORT_NAME_PREFIX GLOBAL PROPERTY
_qt_export_additional_targets_export_name_prefix_${id})
get_property(arg_CONFIG_INSTALL_DIR GLOBAL PROPERTY
_qt_export_additional_targets_config_install_dir_${id})
get_property(arg_TARGETS GLOBAL PROPERTY
_qt_export_additional_targets_${id})
get_property(arg_TARGET_EXPORT_NAMES GLOBAL PROPERTY
_qt_export_additional_target_export_names_${id})
list(LENGTH arg_TARGETS num_TARGETS)
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
# Determine the release configurations we're currently building
if(QT_GENERATOR_IS_MULTI_CONFIG)
set(active_configurations ${CMAKE_CONFIGURATION_TYPES})
else()
set(active_configurations ${CMAKE_BUILD_TYPE})
endif()
unset(active_release_configurations)
foreach(config ${active_configurations})
string(TOUPPER ${config} ucconfig)
if(NOT ucconfig STREQUAL "DEBUG")
list(APPEND active_release_configurations ${config})
endif()
endforeach()
CMake: Write proper *AdditionalTargetInfo file in debug-only build To provide the IMPORTED_LOCATION target property we must write the *AdditionalTargetInfo.cmake file for all debug-only builds, not only the ones containing a release configuration. Task-number: QTBUG-86893 Change-Id: I9ecd01483660f434a3f1ea12fa2af756cdcf9932 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-25 12:08:46 +00:00
if(active_release_configurations)
# Use the first active release configuration as *the* release config for imported targets
# and for QT_DEFAULT_IMPORT_CONFIGURATION.
list(GET active_release_configurations 0 release_cfg)
string(TOUPPER ${release_cfg} uc_release_cfg)
set(uc_default_cfg ${uc_release_cfg})
# Determine the release configurations we do *not* build currently
set(configurations_to_export Release;RelWithDebInfo;MinSizeRel)
list(REMOVE_ITEM configurations_to_export ${active_configurations})
else()
# There are no active release configurations.
# Use the first active configuration for QT_DEFAULT_IMPORT_CONFIGURATION.
unset(uc_release_cfg)
list(GET active_configurations 0 default_cfg)
string(TOUPPER ${default_cfg} uc_default_cfg)
unset(configurations_to_export)
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
endif()
set(content "# Additional target information for ${arg_EXPORT_NAME_PREFIX}
if(NOT DEFINED QT_DEFAULT_IMPORT_CONFIGURATION)
CMake: Write proper *AdditionalTargetInfo file in debug-only build To provide the IMPORTED_LOCATION target property we must write the *AdditionalTargetInfo.cmake file for all debug-only builds, not only the ones containing a release configuration. Task-number: QTBUG-86893 Change-Id: I9ecd01483660f434a3f1ea12fa2af756cdcf9932 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-25 12:08:46 +00:00
set(QT_DEFAULT_IMPORT_CONFIGURATION ${uc_default_cfg})
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
endif()
")
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
CMake: Fix additional target info files ...for QT_BUILD_TOOLS_WHEN_CROSSCOMPILING. qt_internal_export_additional_targets_file now gets two lists of target names when run from qt_export_tools: - TARGETS containing actually existing targets, and - TARGET_EXPORT_NAMES containing the target names as they appear in the additional target info file. Operations that require actual targets are run on the TARGETS, in the additional target info file only TARGET_EXPORT_NAMES are written. This distinction is required for the case where the host Qt lacks a tool that is built in the target Qt. Example: host Qt is built with DEVELOPER_BUILD=OFF, target Qt is built with DEVELOPER_BUILD=ON. Then the host Qt lacks qmljs, but it is built in the target Qt. TARGETS contains qmljs_native, and TARGET_EXPORT_NAMES contains qmljs. Fixes: QTBUG-87693 Change-Id: I615aed996bfcbe654274defcda8c1cb2cc4b7b4e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-10-15 15:11:16 +00:00
math(EXPR n "${num_TARGETS} - 1")
foreach(i RANGE ${n})
list(GET arg_TARGETS ${i} target)
list(GET arg_TARGET_EXPORT_NAMES ${i} target_export_name)
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
CMake: Fix additional target info files ...for QT_BUILD_TOOLS_WHEN_CROSSCOMPILING. qt_internal_export_additional_targets_file now gets two lists of target names when run from qt_export_tools: - TARGETS containing actually existing targets, and - TARGET_EXPORT_NAMES containing the target names as they appear in the additional target info file. Operations that require actual targets are run on the TARGETS, in the additional target info file only TARGET_EXPORT_NAMES are written. This distinction is required for the case where the host Qt lacks a tool that is built in the target Qt. Example: host Qt is built with DEVELOPER_BUILD=OFF, target Qt is built with DEVELOPER_BUILD=ON. Then the host Qt lacks qmljs, but it is built in the target Qt. TARGETS contains qmljs_native, and TARGET_EXPORT_NAMES contains qmljs. Fixes: QTBUG-87693 Change-Id: I615aed996bfcbe654274defcda8c1cb2cc4b7b4e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-10-15 15:11:16 +00:00
set(full_target ${target_export_name})
CMake: Generate *AdditionalTargetInfo.cmake for tools This ensures that we have the configuration-independent IMPORTED_* properties set on tools. Fixes: QTBUG-86893 Change-Id: I2b772c21341e6e4631379d4a5a99580ec96909ed Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-25 10:18:58 +00:00
if(NOT full_target MATCHES "^${QT_CMAKE_EXPORT_NAMESPACE}::")
string(PREPEND full_target "${QT_CMAKE_EXPORT_NAMESPACE}::")
endif()
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
# Tools are already made global unconditionally in QtFooToolsConfig.cmake.
# And the
get_target_property(target_type ${target} TYPE)
if(NOT target_type STREQUAL "EXECUTABLE")
string(APPEND content
"__qt_internal_promote_target_to_global_checked(${full_target})\n")
endif()
# INTERFACE libraries don't have IMPORTED_LOCATION-like properties.
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
# Skip the rest of the processing for those.
CMake: Export additional target info props for object libraries For some reason when building a user project in Release mode, when Qt was built with -DCMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug on MSVC, will result in linking of Debug object libraries into the user project. This does not happen in the same configuration on macOS. My guess is there is a difference in the logic on which configuration to choose between the platforms, perhaps based on package lookup order or something else. This was observed with qtgrpc's ProtobufWellKnownTypes_type_registration object library (which is only built on Windows as an object library). The issue can be fixed if we explicitly generate per-config imported location information for object libraries, just like we do for regular libraries. That way we'll have uniform build type information for all target types. Pick-to: 6.6 6.7 Fixes: QTBUG-119708 Change-Id: I9020b7743cea65bbd92cadd5f570b7e38e999bd4 Reviewed-by: 🌴 Alexey Edelev 🌴 <alexey.edelev@qt.io>
2023-12-14 14:59:21 +00:00
if(target_type STREQUAL "INTERFACE_LIBRARY")
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
continue()
endif()
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
set(properties_retrieved TRUE)
Fix build of Debug projects against debug-and-release non-prefix Qt Building a CMake project with CMAKE_BUILD_CONFIG=Debug was broken for non-prefix debug-and-release builds of Qt. In debug-and-release builds we set EXCLUDE_FROM_ALL on tools in the Debug configuration. In non-prefix builds we export(EXPORT) targets, and that also contains the non-existent Debug variants of the tools. In prefix builds, we install(EXPORT) instead, which only exports what is built and installed. Consequently, we now remove the DEBUG-related import information if the debug variant if the target binary does not exist. Pick-to: 6.2 Fixes: QTBUG-95027 Change-Id: I37766d5ab1e2795bcb91a348e7e72150e8a00f82 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 07:59:05 +00:00
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_target_property(is_configure_time_target ${target} _qt_internal_configure_time_target)
if(is_configure_time_target)
Use the existing imported location for syncqt in developer builds In developer builds we don't install tools, so syncqt executable is located in its RUNTIME_OUTPUT_DIRECTORY but not by install path. This works fine in general case, but in multi-config builds the RUNTIME_OUTPUT_DIRECTORY path doesn't match the install path. So syncqt target points to wrong location in this case. It makes sense to use the existing IMPORTED_LOCATION of syncqt executable directly if Qt is not supposed to be installed. Also check if the syncqt executable exists at the expected location before creating the imported target. Pick-to: 6.5 Fixes: QTBUG-109864 Change-Id: I0de647b2a73169a0d48bd88edeb7ff00975fa774 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2023-01-06 09:23:51 +00:00
# For Multi-config developer builds we should simply reuse IMPORTED_LOCATION of the
# target.
if(NOT QT_WILL_INSTALL AND QT_FEATURE_debug_and_release)
CMake: Fix syncqt IMPORTED_LOCATION path for multi-config builds When building examples as ExternalProjects as part of a multi-config qtbase build, syncqt can not be located with the following error: CMake Error at Qt6CoreToolsAdditionalTargetInfo.cmake:10 (message): Unable to add configure time executable Qt6::syncqt qtbase/libexec/syncqt doesn't exist Call Stack (most recent call first): qtbase/lib/cmake/Qt6CoreTools/Qt6CoreToolsConfig.cmake:44 (include) qtbase/cmake/QtPublicDependencyHelpers.cmake:65 (find_package) qtbase/lib/cmake/Qt6Core/Qt6CoreDependencies.cmake:34 (_qt_internal_find_tool_dependencies) qtbase/lib/cmake/Qt6Core/Qt6CoreConfig.cmake:42 (include) qtbase/lib/cmake/Qt6/Qt6Config.cmake:165 (find_package) CMakeLists.txt:13 (find_package) The Qt6CoreToolsAdditionalTargetInfo.cmake file is used both for install(EXPORT) Config files as well as export(EXPORT) Config files, and in the latter case, the path that syncqt is looked up in is not correct because syncqt is not yet installed. In addition to checking whether syncqt exists in the install path, also check if it exists in the build dir. Ideally the additional path would be stored in a separate file that is not installed, but the current code infrastructure does not provide such a feature. Because we store a relative path instead of an absolute path, the build path does not leak, so the situation is bearable. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I16ad5c280751e050bc9b039ebd38ec9a66a6554c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-05 13:21:25 +00:00
set(configure_time_target_build_location "")
Use the existing imported location for syncqt in developer builds In developer builds we don't install tools, so syncqt executable is located in its RUNTIME_OUTPUT_DIRECTORY but not by install path. This works fine in general case, but in multi-config builds the RUNTIME_OUTPUT_DIRECTORY path doesn't match the install path. So syncqt target points to wrong location in this case. It makes sense to use the existing IMPORTED_LOCATION of syncqt executable directly if Qt is not supposed to be installed. Also check if the syncqt executable exists at the expected location before creating the imported target. Pick-to: 6.5 Fixes: QTBUG-109864 Change-Id: I0de647b2a73169a0d48bd88edeb7ff00975fa774 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2023-01-06 09:23:51 +00:00
get_target_property(configure_time_target_install_location ${target}
IMPORTED_LOCATION)
else()
Avoid using PACKAGE_PREFIX_PATH for configure-time executables PACKAGE_PREFIX_PATH is not defined in cmake versions 3.29.x. We should avoid referring the internal CMake variables. Use the calculated reverse relative path to the prefix path instead. Fixes: QTBUG-124186 Pick-to: 6.5 6.6 6.7 Change-Id: Iefae132e61a3f8e8f5525c0abd6a2d41631c2fb0 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2024-04-08 12:49:39 +00:00
if(IS_ABSOLUTE "${arg_CONFIG_INSTALL_DIR}")
file(RELATIVE_PATH reverse_relative_prefix_path
"${arg_CONFIG_INSTALL_DIR}" "${CMAKE_INSTALL_PREFIX}")
else()
file(RELATIVE_PATH reverse_relative_prefix_path
"${CMAKE_INSTALL_PREFIX}/${arg_CONFIG_INSTALL_DIR}"
"${CMAKE_INSTALL_PREFIX}")
endif()
CMake: Fix syncqt IMPORTED_LOCATION path for multi-config builds When building examples as ExternalProjects as part of a multi-config qtbase build, syncqt can not be located with the following error: CMake Error at Qt6CoreToolsAdditionalTargetInfo.cmake:10 (message): Unable to add configure time executable Qt6::syncqt qtbase/libexec/syncqt doesn't exist Call Stack (most recent call first): qtbase/lib/cmake/Qt6CoreTools/Qt6CoreToolsConfig.cmake:44 (include) qtbase/cmake/QtPublicDependencyHelpers.cmake:65 (find_package) qtbase/lib/cmake/Qt6Core/Qt6CoreDependencies.cmake:34 (_qt_internal_find_tool_dependencies) qtbase/lib/cmake/Qt6Core/Qt6CoreConfig.cmake:42 (include) qtbase/lib/cmake/Qt6/Qt6Config.cmake:165 (find_package) CMakeLists.txt:13 (find_package) The Qt6CoreToolsAdditionalTargetInfo.cmake file is used both for install(EXPORT) Config files as well as export(EXPORT) Config files, and in the latter case, the path that syncqt is looked up in is not correct because syncqt is not yet installed. In addition to checking whether syncqt exists in the install path, also check if it exists in the build dir. Ideally the additional path would be stored in a separate file that is not installed, but the current code infrastructure does not provide such a feature. Because we store a relative path instead of an absolute path, the build path does not leak, so the situation is bearable. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I16ad5c280751e050bc9b039ebd38ec9a66a6554c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-05 13:21:25 +00:00
get_target_property(configure_time_target_build_location ${target}
_qt_internal_configure_time_target_build_location)
Avoid using PACKAGE_PREFIX_PATH for configure-time executables PACKAGE_PREFIX_PATH is not defined in cmake versions 3.29.x. We should avoid referring the internal CMake variables. Use the calculated reverse relative path to the prefix path instead. Fixes: QTBUG-124186 Pick-to: 6.5 6.6 6.7 Change-Id: Iefae132e61a3f8e8f5525c0abd6a2d41631c2fb0 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2024-04-08 12:49:39 +00:00
string(TOUPPER "${QT_CMAKE_EXPORT_NAMESPACE}_INSTALL_PREFIX" install_prefix_var)
string(JOIN "" configure_time_target_build_location
"$\{CMAKE_CURRENT_LIST_DIR}/"
"${reverse_relative_prefix_path}"
"${configure_time_target_build_location}")
CMake: Fix syncqt IMPORTED_LOCATION path for multi-config builds When building examples as ExternalProjects as part of a multi-config qtbase build, syncqt can not be located with the following error: CMake Error at Qt6CoreToolsAdditionalTargetInfo.cmake:10 (message): Unable to add configure time executable Qt6::syncqt qtbase/libexec/syncqt doesn't exist Call Stack (most recent call first): qtbase/lib/cmake/Qt6CoreTools/Qt6CoreToolsConfig.cmake:44 (include) qtbase/cmake/QtPublicDependencyHelpers.cmake:65 (find_package) qtbase/lib/cmake/Qt6Core/Qt6CoreDependencies.cmake:34 (_qt_internal_find_tool_dependencies) qtbase/lib/cmake/Qt6Core/Qt6CoreConfig.cmake:42 (include) qtbase/lib/cmake/Qt6/Qt6Config.cmake:165 (find_package) CMakeLists.txt:13 (find_package) The Qt6CoreToolsAdditionalTargetInfo.cmake file is used both for install(EXPORT) Config files as well as export(EXPORT) Config files, and in the latter case, the path that syncqt is looked up in is not correct because syncqt is not yet installed. In addition to checking whether syncqt exists in the install path, also check if it exists in the build dir. Ideally the additional path would be stored in a separate file that is not installed, but the current code infrastructure does not provide such a feature. Because we store a relative path instead of an absolute path, the build path does not leak, so the situation is bearable. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I16ad5c280751e050bc9b039ebd38ec9a66a6554c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-05 13:21:25 +00:00
Use the existing imported location for syncqt in developer builds In developer builds we don't install tools, so syncqt executable is located in its RUNTIME_OUTPUT_DIRECTORY but not by install path. This works fine in general case, but in multi-config builds the RUNTIME_OUTPUT_DIRECTORY path doesn't match the install path. So syncqt target points to wrong location in this case. It makes sense to use the existing IMPORTED_LOCATION of syncqt executable directly if Qt is not supposed to be installed. Also check if the syncqt executable exists at the expected location before creating the imported target. Pick-to: 6.5 Fixes: QTBUG-109864 Change-Id: I0de647b2a73169a0d48bd88edeb7ff00975fa774 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2023-01-06 09:23:51 +00:00
get_target_property(configure_time_target_install_location ${target}
_qt_internal_configure_time_target_install_location)
CMake: Fix syncqt IMPORTED_LOCATION path for multi-config builds When building examples as ExternalProjects as part of a multi-config qtbase build, syncqt can not be located with the following error: CMake Error at Qt6CoreToolsAdditionalTargetInfo.cmake:10 (message): Unable to add configure time executable Qt6::syncqt qtbase/libexec/syncqt doesn't exist Call Stack (most recent call first): qtbase/lib/cmake/Qt6CoreTools/Qt6CoreToolsConfig.cmake:44 (include) qtbase/cmake/QtPublicDependencyHelpers.cmake:65 (find_package) qtbase/lib/cmake/Qt6Core/Qt6CoreDependencies.cmake:34 (_qt_internal_find_tool_dependencies) qtbase/lib/cmake/Qt6Core/Qt6CoreConfig.cmake:42 (include) qtbase/lib/cmake/Qt6/Qt6Config.cmake:165 (find_package) CMakeLists.txt:13 (find_package) The Qt6CoreToolsAdditionalTargetInfo.cmake file is used both for install(EXPORT) Config files as well as export(EXPORT) Config files, and in the latter case, the path that syncqt is looked up in is not correct because syncqt is not yet installed. In addition to checking whether syncqt exists in the install path, also check if it exists in the build dir. Ideally the additional path would be stored in a separate file that is not installed, but the current code infrastructure does not provide such a feature. Because we store a relative path instead of an absolute path, the build path does not leak, so the situation is bearable. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I16ad5c280751e050bc9b039ebd38ec9a66a6554c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-05 13:21:25 +00:00
Avoid using PACKAGE_PREFIX_PATH for configure-time executables PACKAGE_PREFIX_PATH is not defined in cmake versions 3.29.x. We should avoid referring the internal CMake variables. Use the calculated reverse relative path to the prefix path instead. Fixes: QTBUG-124186 Pick-to: 6.5 6.6 6.7 Change-Id: Iefae132e61a3f8e8f5525c0abd6a2d41631c2fb0 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2024-04-08 12:49:39 +00:00
string(JOIN "" configure_time_target_install_location
"$\{CMAKE_CURRENT_LIST_DIR}/"
"${reverse_relative_prefix_path}"
"${configure_time_target_install_location}")
Use the existing imported location for syncqt in developer builds In developer builds we don't install tools, so syncqt executable is located in its RUNTIME_OUTPUT_DIRECTORY but not by install path. This works fine in general case, but in multi-config builds the RUNTIME_OUTPUT_DIRECTORY path doesn't match the install path. So syncqt target points to wrong location in this case. It makes sense to use the existing IMPORTED_LOCATION of syncqt executable directly if Qt is not supposed to be installed. Also check if the syncqt executable exists at the expected location before creating the imported target. Pick-to: 6.5 Fixes: QTBUG-109864 Change-Id: I0de647b2a73169a0d48bd88edeb7ff00975fa774 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2023-01-06 09:23:51 +00:00
endif()
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
if(configure_time_target_install_location)
string(APPEND content "
# Import configure-time executable ${full_target}
if(NOT TARGET ${full_target})
CMake: Fix syncqt IMPORTED_LOCATION path for multi-config builds When building examples as ExternalProjects as part of a multi-config qtbase build, syncqt can not be located with the following error: CMake Error at Qt6CoreToolsAdditionalTargetInfo.cmake:10 (message): Unable to add configure time executable Qt6::syncqt qtbase/libexec/syncqt doesn't exist Call Stack (most recent call first): qtbase/lib/cmake/Qt6CoreTools/Qt6CoreToolsConfig.cmake:44 (include) qtbase/cmake/QtPublicDependencyHelpers.cmake:65 (find_package) qtbase/lib/cmake/Qt6Core/Qt6CoreDependencies.cmake:34 (_qt_internal_find_tool_dependencies) qtbase/lib/cmake/Qt6Core/Qt6CoreConfig.cmake:42 (include) qtbase/lib/cmake/Qt6/Qt6Config.cmake:165 (find_package) CMakeLists.txt:13 (find_package) The Qt6CoreToolsAdditionalTargetInfo.cmake file is used both for install(EXPORT) Config files as well as export(EXPORT) Config files, and in the latter case, the path that syncqt is looked up in is not correct because syncqt is not yet installed. In addition to checking whether syncqt exists in the install path, also check if it exists in the build dir. Ideally the additional path would be stored in a separate file that is not installed, but the current code infrastructure does not provide such a feature. Because we store a relative path instead of an absolute path, the build path does not leak, so the situation is bearable. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I16ad5c280751e050bc9b039ebd38ec9a66a6554c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-05 13:21:25 +00:00
set(_qt_imported_build_location \"${configure_time_target_build_location}\")
set(_qt_imported_install_location \"${configure_time_target_install_location}\")
set(_qt_imported_location \"\${_qt_imported_install_location}\")
if(NOT EXISTS \"$\{_qt_imported_location}\"
AND NOT \"$\{_qt_imported_build_location}\" STREQUAL \"\")
set(_qt_imported_location \"\${_qt_imported_build_location}\")
endif()
Use the existing imported location for syncqt in developer builds In developer builds we don't install tools, so syncqt executable is located in its RUNTIME_OUTPUT_DIRECTORY but not by install path. This works fine in general case, but in multi-config builds the RUNTIME_OUTPUT_DIRECTORY path doesn't match the install path. So syncqt target points to wrong location in this case. It makes sense to use the existing IMPORTED_LOCATION of syncqt executable directly if Qt is not supposed to be installed. Also check if the syncqt executable exists at the expected location before creating the imported target. Pick-to: 6.5 Fixes: QTBUG-109864 Change-Id: I0de647b2a73169a0d48bd88edeb7ff00975fa774 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2023-01-06 09:23:51 +00:00
if(NOT EXISTS \"$\{_qt_imported_location}\")
message(FATAL_ERROR \"Unable to add configure time executable ${full_target}\"
\" $\{_qt_imported_location} doesn't exists\")
endif()
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_executable(${full_target} IMPORTED)
set_property(TARGET ${full_target} APPEND PROPERTY IMPORTED_CONFIGURATIONS ${default_cfg})
set_target_properties(${full_target} PROPERTIES IMPORTED_LOCATION_${uc_default_cfg}
Use the existing imported location for syncqt in developer builds In developer builds we don't install tools, so syncqt executable is located in its RUNTIME_OUTPUT_DIRECTORY but not by install path. This works fine in general case, but in multi-config builds the RUNTIME_OUTPUT_DIRECTORY path doesn't match the install path. So syncqt target points to wrong location in this case. It makes sense to use the existing IMPORTED_LOCATION of syncqt executable directly if Qt is not supposed to be installed. Also check if the syncqt executable exists at the expected location before creating the imported target. Pick-to: 6.5 Fixes: QTBUG-109864 Change-Id: I0de647b2a73169a0d48bd88edeb7ff00975fa774 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2023-01-06 09:23:51 +00:00
\"$\{_qt_imported_location}\")
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_property(TARGET ${full_target} PROPERTY IMPORTED_GLOBAL TRUE)
Use the existing imported location for syncqt in developer builds In developer builds we don't install tools, so syncqt executable is located in its RUNTIME_OUTPUT_DIRECTORY but not by install path. This works fine in general case, but in multi-config builds the RUNTIME_OUTPUT_DIRECTORY path doesn't match the install path. So syncqt target points to wrong location in this case. It makes sense to use the existing IMPORTED_LOCATION of syncqt executable directly if Qt is not supposed to be installed. Also check if the syncqt executable exists at the expected location before creating the imported target. Pick-to: 6.5 Fixes: QTBUG-109864 Change-Id: I0de647b2a73169a0d48bd88edeb7ff00975fa774 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2023-01-06 09:23:51 +00:00
unset(_qt_imported_location)
CMake: Fix syncqt IMPORTED_LOCATION path for multi-config builds When building examples as ExternalProjects as part of a multi-config qtbase build, syncqt can not be located with the following error: CMake Error at Qt6CoreToolsAdditionalTargetInfo.cmake:10 (message): Unable to add configure time executable Qt6::syncqt qtbase/libexec/syncqt doesn't exist Call Stack (most recent call first): qtbase/lib/cmake/Qt6CoreTools/Qt6CoreToolsConfig.cmake:44 (include) qtbase/cmake/QtPublicDependencyHelpers.cmake:65 (find_package) qtbase/lib/cmake/Qt6Core/Qt6CoreDependencies.cmake:34 (_qt_internal_find_tool_dependencies) qtbase/lib/cmake/Qt6Core/Qt6CoreConfig.cmake:42 (include) qtbase/lib/cmake/Qt6/Qt6Config.cmake:165 (find_package) CMakeLists.txt:13 (find_package) The Qt6CoreToolsAdditionalTargetInfo.cmake file is used both for install(EXPORT) Config files as well as export(EXPORT) Config files, and in the latter case, the path that syncqt is looked up in is not correct because syncqt is not yet installed. In addition to checking whether syncqt exists in the install path, also check if it exists in the build dir. Ideally the additional path would be stored in a separate file that is not installed, but the current code infrastructure does not provide such a feature. Because we store a relative path instead of an absolute path, the build path does not leak, so the situation is bearable. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I16ad5c280751e050bc9b039ebd38ec9a66a6554c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-05 13:21:25 +00:00
unset(_qt_imported_build_location)
unset(_qt_imported_install_location)
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()
\n")
endif()
endif()
Fix build of Debug projects against debug-and-release non-prefix Qt Building a CMake project with CMAKE_BUILD_CONFIG=Debug was broken for non-prefix debug-and-release builds of Qt. In debug-and-release builds we set EXCLUDE_FROM_ALL on tools in the Debug configuration. In non-prefix builds we export(EXPORT) targets, and that also contains the non-existent Debug variants of the tools. In prefix builds, we install(EXPORT) instead, which only exports what is built and installed. Consequently, we now remove the DEBUG-related import information if the debug variant if the target binary does not exist. Pick-to: 6.2 Fixes: QTBUG-95027 Change-Id: I37766d5ab1e2795bcb91a348e7e72150e8a00f82 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 07:59:05 +00:00
# Non-prefix debug-and-release builds: add check for the existence of the debug binary of
# the target. It is not built by default.
if(NOT QT_WILL_INSTALL AND QT_FEATURE_debug_and_release)
get_target_property(excluded_genex ${target} EXCLUDE_FROM_ALL)
CMake: Fix non-prefix debug exclusion check for additional info props The condition was checking if excluded_genex variables is not an empty string. But when the EXCLUDE_FROM_ALL property was unset, the value of excluded_genex would be "excluded_genex-NOTFOUND" which would fail the condition, and would end up always adding the generated code block. Instead of checking for an empty string, check if it's a truth-y value. This ensures not to add the code block when the property is unset. Amends 7540b4bd5634c9104a99f9b219531b1e3dd7942d Change-Id: I126c745e2e6eccad34171456c052a14cad9d887d Pick-to: 6.7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: 🌴 Alexey Edelev 🌴 <alexey.edelev@qt.io>
2023-12-14 15:11:24 +00:00
if(excluded_genex)
Fix build of Debug projects against debug-and-release non-prefix Qt Building a CMake project with CMAKE_BUILD_CONFIG=Debug was broken for non-prefix debug-and-release builds of Qt. In debug-and-release builds we set EXCLUDE_FROM_ALL on tools in the Debug configuration. In non-prefix builds we export(EXPORT) targets, and that also contains the non-existent Debug variants of the tools. In prefix builds, we install(EXPORT) instead, which only exports what is built and installed. Consequently, we now remove the DEBUG-related import information if the debug variant if the target binary does not exist. Pick-to: 6.2 Fixes: QTBUG-95027 Change-Id: I37766d5ab1e2795bcb91a348e7e72150e8a00f82 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 07:59:05 +00:00
string(APPEND content "
# ${full_target} is not built by default in the Debug configuration. Check existence.
get_target_property(_qt_imported_location ${full_target} IMPORTED_LOCATION_DEBUG)
Replace the impl of qt_configure_file with qt_configure_file_v2 The new version uses PARSE_ARGV which deals with semicolons better. Task-number: QTBUG-99238 Change-Id: Ie9276219400326a67ffa9cf5fc456ae7de0bbcd2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-01-11 13:02:13 +00:00
if(NOT EXISTS \"$\{_qt_imported_location}\")
Fix build of Debug projects against debug-and-release non-prefix Qt Building a CMake project with CMAKE_BUILD_CONFIG=Debug was broken for non-prefix debug-and-release builds of Qt. In debug-and-release builds we set EXCLUDE_FROM_ALL on tools in the Debug configuration. In non-prefix builds we export(EXPORT) targets, and that also contains the non-existent Debug variants of the tools. In prefix builds, we install(EXPORT) instead, which only exports what is built and installed. Consequently, we now remove the DEBUG-related import information if the debug variant if the target binary does not exist. Pick-to: 6.2 Fixes: QTBUG-95027 Change-Id: I37766d5ab1e2795bcb91a348e7e72150e8a00f82 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 07:59:05 +00:00
get_target_property(_qt_imported_configs ${full_target} IMPORTED_CONFIGURATIONS)
list(REMOVE_ITEM _qt_imported_configs DEBUG)
Replace the impl of qt_configure_file with qt_configure_file_v2 The new version uses PARSE_ARGV which deals with semicolons better. Task-number: QTBUG-99238 Change-Id: Ie9276219400326a67ffa9cf5fc456ae7de0bbcd2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-01-11 13:02:13 +00:00
set_property(TARGET ${full_target} PROPERTY IMPORTED_CONFIGURATIONS $\{_qt_imported_configs})
Fix build of Debug projects against debug-and-release non-prefix Qt Building a CMake project with CMAKE_BUILD_CONFIG=Debug was broken for non-prefix debug-and-release builds of Qt. In debug-and-release builds we set EXCLUDE_FROM_ALL on tools in the Debug configuration. In non-prefix builds we export(EXPORT) targets, and that also contains the non-existent Debug variants of the tools. In prefix builds, we install(EXPORT) instead, which only exports what is built and installed. Consequently, we now remove the DEBUG-related import information if the debug variant if the target binary does not exist. Pick-to: 6.2 Fixes: QTBUG-95027 Change-Id: I37766d5ab1e2795bcb91a348e7e72150e8a00f82 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 07:59:05 +00:00
set_property(TARGET ${full_target} PROPERTY IMPORTED_LOCATION_DEBUG)
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()\n")
Fix build of Debug projects against debug-and-release non-prefix Qt Building a CMake project with CMAKE_BUILD_CONFIG=Debug was broken for non-prefix debug-and-release builds of Qt. In debug-and-release builds we set EXCLUDE_FROM_ALL on tools in the Debug configuration. In non-prefix builds we export(EXPORT) targets, and that also contains the non-existent Debug variants of the tools. In prefix builds, we install(EXPORT) instead, which only exports what is built and installed. Consequently, we now remove the DEBUG-related import information if the debug variant if the target binary does not exist. Pick-to: 6.2 Fixes: QTBUG-95027 Change-Id: I37766d5ab1e2795bcb91a348e7e72150e8a00f82 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 07:59:05 +00:00
endif()
endif()
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
set(write_implib FALSE)
set(write_soname FALSE)
CMake: Export additional target info props for object libraries For some reason when building a user project in Release mode, when Qt was built with -DCMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug on MSVC, will result in linking of Debug object libraries into the user project. This does not happen in the same configuration on macOS. My guess is there is a difference in the logic on which configuration to choose between the platforms, perhaps based on package lookup order or something else. This was observed with qtgrpc's ProtobufWellKnownTypes_type_registration object library (which is only built on Windows as an object library). The issue can be fixed if we explicitly generate per-config imported location information for object libraries, just like we do for regular libraries. That way we'll have uniform build type information for all target types. Pick-to: 6.6 6.7 Fixes: QTBUG-119708 Change-Id: I9020b7743cea65bbd92cadd5f570b7e38e999bd4 Reviewed-by: 🌴 Alexey Edelev 🌴 <alexey.edelev@qt.io>
2023-12-14 14:59:21 +00:00
set(write_objects FALSE)
CMake: Write link dependencies into AdditionalTargetInfo.cmake file When a shared library target has private dependencies to another shared library, they are exported by CMake into the target's IMPORTED_LINK_DEPENDENT_LIBRARIES_<CONFIG> property. This property then is read by the consuming project to determine which file paths need to be added to the -rpath-link linker option. Due to the simple logic that CMake uses to process this property, if the project CMAKE_BUILD_TYPE does not match the _<CONFIG> part of the property, the dependent libraries will not be added to -rpath-link, causing link failures. Make sure we explicitly set all the possible variants of the property in our custom Qt6FooAdditionalTargetInfo.cmake file, to ensure we always pick up the relevant dependent libraries for processing. In conjunction with 173164cd477211e574c0d04abef51aa0f4c3f78d and 1c287cea291d2a88770ff02771845d2a34e80964 in qtbase, this should hopefully avoid most -rpath-linking issues for QNX and Yocto builds. Pick-to: 6.8 Task-number: QTBUG-126727 Change-Id: I16a9cb5553d57e5ea3edc28cc2aab89c77f02a75 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-07-01 14:00:46 +00:00
set(write_link_dependencies FALSE)
CMake: Export additional target info props for object libraries For some reason when building a user project in Release mode, when Qt was built with -DCMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug on MSVC, will result in linking of Debug object libraries into the user project. This does not happen in the same configuration on macOS. My guess is there is a difference in the logic on which configuration to choose between the platforms, perhaps based on package lookup order or something else. This was observed with qtgrpc's ProtobufWellKnownTypes_type_registration object library (which is only built on Windows as an object library). The issue can be fixed if we explicitly generate per-config imported location information for object libraries, just like we do for regular libraries. That way we'll have uniform build type information for all target types. Pick-to: 6.6 6.7 Fixes: QTBUG-119708 Change-Id: I9020b7743cea65bbd92cadd5f570b7e38e999bd4 Reviewed-by: 🌴 Alexey Edelev 🌴 <alexey.edelev@qt.io>
2023-12-14 14:59:21 +00:00
set(write_location TRUE)
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
if(target_type STREQUAL "SHARED_LIBRARY")
CMake: Fix IMPORTED_IMPLIB to be set for shared libraries on Windows The correct variable to check is WIN32, not WINDOWS. Amends 85e25d93b3b99fbeae8541586252df2cb099081d Pick-to: 6.2 Change-Id: I4570eb5a124bcaa0bd38135dd7c7f48345c40c9d Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2021-07-14 09:14:51 +00:00
if(WIN32)
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
set(write_implib TRUE)
wasm: add support for building Qt as shared libraries This implements the build system bits required to build Qt as as separate wasm modules a.k.a Emscripten side modules. Enable by configuring with the "-shared" flag. This is the first step towards shared library support and gets us as far as being able to load QtCore and instantiate a QCoreApplication. Task-number: QTBUG-63925 Change-Id: Ib8f07f80fb5b13c8dbba65c7db735dc557b70d0e Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
2022-08-19 12:25:49 +00:00
elseif(WASM)
# Keep write_soname at FALSE
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
else()
set(write_soname TRUE)
endif()
CMake: Write link dependencies into AdditionalTargetInfo.cmake file When a shared library target has private dependencies to another shared library, they are exported by CMake into the target's IMPORTED_LINK_DEPENDENT_LIBRARIES_<CONFIG> property. This property then is read by the consuming project to determine which file paths need to be added to the -rpath-link linker option. Due to the simple logic that CMake uses to process this property, if the project CMAKE_BUILD_TYPE does not match the _<CONFIG> part of the property, the dependent libraries will not be added to -rpath-link, causing link failures. Make sure we explicitly set all the possible variants of the property in our custom Qt6FooAdditionalTargetInfo.cmake file, to ensure we always pick up the relevant dependent libraries for processing. In conjunction with 173164cd477211e574c0d04abef51aa0f4c3f78d and 1c287cea291d2a88770ff02771845d2a34e80964 in qtbase, this should hopefully avoid most -rpath-linking issues for QNX and Yocto builds. Pick-to: 6.8 Task-number: QTBUG-126727 Change-Id: I16a9cb5553d57e5ea3edc28cc2aab89c77f02a75 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-07-01 14:00:46 +00:00
set(write_link_dependencies TRUE)
CMake: Export additional target info props for object libraries For some reason when building a user project in Release mode, when Qt was built with -DCMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug on MSVC, will result in linking of Debug object libraries into the user project. This does not happen in the same configuration on macOS. My guess is there is a difference in the logic on which configuration to choose between the platforms, perhaps based on package lookup order or something else. This was observed with qtgrpc's ProtobufWellKnownTypes_type_registration object library (which is only built on Windows as an object library). The issue can be fixed if we explicitly generate per-config imported location information for object libraries, just like we do for regular libraries. That way we'll have uniform build type information for all target types. Pick-to: 6.6 6.7 Fixes: QTBUG-119708 Change-Id: I9020b7743cea65bbd92cadd5f570b7e38e999bd4 Reviewed-by: 🌴 Alexey Edelev 🌴 <alexey.edelev@qt.io>
2023-12-14 14:59:21 +00:00
elseif(target_type STREQUAL "OBJECT_LIBRARY")
set(write_objects TRUE)
set(write_location FALSE)
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
endif()
CMake: Write proper *AdditionalTargetInfo file in debug-only build To provide the IMPORTED_LOCATION target property we must write the *AdditionalTargetInfo.cmake file for all debug-only builds, not only the ones containing a release configuration. Task-number: QTBUG-86893 Change-Id: I9ecd01483660f434a3f1ea12fa2af756cdcf9932 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-25 12:08:46 +00:00
if(NOT "${uc_release_cfg}" STREQUAL "")
CMake: Export additional target info props for object libraries For some reason when building a user project in Release mode, when Qt was built with -DCMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug on MSVC, will result in linking of Debug object libraries into the user project. This does not happen in the same configuration on macOS. My guess is there is a difference in the logic on which configuration to choose between the platforms, perhaps based on package lookup order or something else. This was observed with qtgrpc's ProtobufWellKnownTypes_type_registration object library (which is only built on Windows as an object library). The issue can be fixed if we explicitly generate per-config imported location information for object libraries, just like we do for regular libraries. That way we'll have uniform build type information for all target types. Pick-to: 6.6 6.7 Fixes: QTBUG-119708 Change-Id: I9020b7743cea65bbd92cadd5f570b7e38e999bd4 Reviewed-by: 🌴 Alexey Edelev 🌴 <alexey.edelev@qt.io>
2023-12-14 14:59:21 +00:00
if(write_location)
string(APPEND content "get_target_property(_qt_imported_location ${full_target} IMPORTED_LOCATION_${uc_release_cfg})\n")
endif()
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
if(write_implib)
string(APPEND content "get_target_property(_qt_imported_implib ${full_target} IMPORTED_IMPLIB_${uc_release_cfg})\n")
endif()
if(write_soname)
string(APPEND content "get_target_property(_qt_imported_soname ${full_target} IMPORTED_SONAME_${uc_release_cfg})\n")
endif()
CMake: Write link dependencies into AdditionalTargetInfo.cmake file When a shared library target has private dependencies to another shared library, they are exported by CMake into the target's IMPORTED_LINK_DEPENDENT_LIBRARIES_<CONFIG> property. This property then is read by the consuming project to determine which file paths need to be added to the -rpath-link linker option. Due to the simple logic that CMake uses to process this property, if the project CMAKE_BUILD_TYPE does not match the _<CONFIG> part of the property, the dependent libraries will not be added to -rpath-link, causing link failures. Make sure we explicitly set all the possible variants of the property in our custom Qt6FooAdditionalTargetInfo.cmake file, to ensure we always pick up the relevant dependent libraries for processing. In conjunction with 173164cd477211e574c0d04abef51aa0f4c3f78d and 1c287cea291d2a88770ff02771845d2a34e80964 in qtbase, this should hopefully avoid most -rpath-linking issues for QNX and Yocto builds. Pick-to: 6.8 Task-number: QTBUG-126727 Change-Id: I16a9cb5553d57e5ea3edc28cc2aab89c77f02a75 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-07-01 14:00:46 +00:00
if(write_link_dependencies)
string(APPEND content "get_target_property(_qt_imported_link_dependencies ${full_target} IMPORTED_LINK_DEPENDENT_LIBRARIES_${uc_release_cfg})\n")
endif()
CMake: Export additional target info props for object libraries For some reason when building a user project in Release mode, when Qt was built with -DCMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug on MSVC, will result in linking of Debug object libraries into the user project. This does not happen in the same configuration on macOS. My guess is there is a difference in the logic on which configuration to choose between the platforms, perhaps based on package lookup order or something else. This was observed with qtgrpc's ProtobufWellKnownTypes_type_registration object library (which is only built on Windows as an object library). The issue can be fixed if we explicitly generate per-config imported location information for object libraries, just like we do for regular libraries. That way we'll have uniform build type information for all target types. Pick-to: 6.6 6.7 Fixes: QTBUG-119708 Change-Id: I9020b7743cea65bbd92cadd5f570b7e38e999bd4 Reviewed-by: 🌴 Alexey Edelev 🌴 <alexey.edelev@qt.io>
2023-12-14 14:59:21 +00:00
if(write_objects)
string(APPEND content "get_target_property(_qt_imported_objects ${full_target} IMPORTED_OBJECTS_${uc_release_cfg})\n")
# We generate CLR props as well, because that's what CMake generates for object
# libraries with CMake 3.27. They are usually empty strings though, aka "".
string(APPEND content "get_target_property(_qt_imported_clr ${full_target} IMPORTED_COMMON_LANGUAGE_RUNTIME_${uc_release_cfg})\n")
endif()
endif()
if(write_location)
string(APPEND content "get_target_property(_qt_imported_location_default ${full_target} IMPORTED_LOCATION_$\{QT_DEFAULT_IMPORT_CONFIGURATION})\n")
CMake: Write proper *AdditionalTargetInfo file in debug-only build To provide the IMPORTED_LOCATION target property we must write the *AdditionalTargetInfo.cmake file for all debug-only builds, not only the ones containing a release configuration. Task-number: QTBUG-86893 Change-Id: I9ecd01483660f434a3f1ea12fa2af756cdcf9932 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-25 12:08:46 +00:00
endif()
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
if(write_implib)
Replace the impl of qt_configure_file with qt_configure_file_v2 The new version uses PARSE_ARGV which deals with semicolons better. Task-number: QTBUG-99238 Change-Id: Ie9276219400326a67ffa9cf5fc456ae7de0bbcd2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-01-11 13:02:13 +00:00
string(APPEND content "get_target_property(_qt_imported_implib_default ${full_target} IMPORTED_IMPLIB_$\{QT_DEFAULT_IMPORT_CONFIGURATION})\n")
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
endif()
if(write_soname)
Replace the impl of qt_configure_file with qt_configure_file_v2 The new version uses PARSE_ARGV which deals with semicolons better. Task-number: QTBUG-99238 Change-Id: Ie9276219400326a67ffa9cf5fc456ae7de0bbcd2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-01-11 13:02:13 +00:00
string(APPEND content "get_target_property(_qt_imported_soname_default ${full_target} IMPORTED_SONAME_$\{QT_DEFAULT_IMPORT_CONFIGURATION})\n")
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
endif()
CMake: Write link dependencies into AdditionalTargetInfo.cmake file When a shared library target has private dependencies to another shared library, they are exported by CMake into the target's IMPORTED_LINK_DEPENDENT_LIBRARIES_<CONFIG> property. This property then is read by the consuming project to determine which file paths need to be added to the -rpath-link linker option. Due to the simple logic that CMake uses to process this property, if the project CMAKE_BUILD_TYPE does not match the _<CONFIG> part of the property, the dependent libraries will not be added to -rpath-link, causing link failures. Make sure we explicitly set all the possible variants of the property in our custom Qt6FooAdditionalTargetInfo.cmake file, to ensure we always pick up the relevant dependent libraries for processing. In conjunction with 173164cd477211e574c0d04abef51aa0f4c3f78d and 1c287cea291d2a88770ff02771845d2a34e80964 in qtbase, this should hopefully avoid most -rpath-linking issues for QNX and Yocto builds. Pick-to: 6.8 Task-number: QTBUG-126727 Change-Id: I16a9cb5553d57e5ea3edc28cc2aab89c77f02a75 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-07-01 14:00:46 +00:00
if(write_link_dependencies)
string(APPEND content "get_target_property(_qt_imported_link_dependencies_default ${full_target} IMPORTED_LINK_DEPENDENT_LIBRARIES_$\{QT_DEFAULT_IMPORT_CONFIGURATION})\n")
endif()
CMake: Export additional target info props for object libraries For some reason when building a user project in Release mode, when Qt was built with -DCMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug on MSVC, will result in linking of Debug object libraries into the user project. This does not happen in the same configuration on macOS. My guess is there is a difference in the logic on which configuration to choose between the platforms, perhaps based on package lookup order or something else. This was observed with qtgrpc's ProtobufWellKnownTypes_type_registration object library (which is only built on Windows as an object library). The issue can be fixed if we explicitly generate per-config imported location information for object libraries, just like we do for regular libraries. That way we'll have uniform build type information for all target types. Pick-to: 6.6 6.7 Fixes: QTBUG-119708 Change-Id: I9020b7743cea65bbd92cadd5f570b7e38e999bd4 Reviewed-by: 🌴 Alexey Edelev 🌴 <alexey.edelev@qt.io>
2023-12-14 14:59:21 +00:00
if(write_objects)
string(APPEND content "get_target_property(_qt_imported_objects_default ${full_target} IMPORTED_OBJECTS_$\{QT_DEFAULT_IMPORT_CONFIGURATION})\n")
string(APPEND content "get_target_property(_qt_imported_clr_default ${full_target} IMPORTED_COMMON_LANGUAGE_RUNTIME_$\{QT_DEFAULT_IMPORT_CONFIGURATION})\n")
endif()
CMake: Write proper *AdditionalTargetInfo file in debug-only build To provide the IMPORTED_LOCATION target property we must write the *AdditionalTargetInfo.cmake file for all debug-only builds, not only the ones containing a release configuration. Task-number: QTBUG-86893 Change-Id: I9ecd01483660f434a3f1ea12fa2af756cdcf9932 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-25 12:08:46 +00:00
foreach(config ${configurations_to_export} "")
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
string(TOUPPER "${config}" ucconfig)
if("${config}" STREQUAL "")
set(property_suffix "")
set(var_suffix "_default")
string(APPEND content "\n# Default configuration")
else()
set(property_suffix "_${ucconfig}")
set(var_suffix "")
string(APPEND content "
# Import target \"${full_target}\" for configuration \"${config}\"
set_property(TARGET ${full_target} APPEND PROPERTY IMPORTED_CONFIGURATIONS ${ucconfig})
")
endif()
CMake: Export additional target info props for object libraries For some reason when building a user project in Release mode, when Qt was built with -DCMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug on MSVC, will result in linking of Debug object libraries into the user project. This does not happen in the same configuration on macOS. My guess is there is a difference in the logic on which configuration to choose between the platforms, perhaps based on package lookup order or something else. This was observed with qtgrpc's ProtobufWellKnownTypes_type_registration object library (which is only built on Windows as an object library). The issue can be fixed if we explicitly generate per-config imported location information for object libraries, just like we do for regular libraries. That way we'll have uniform build type information for all target types. Pick-to: 6.6 6.7 Fixes: QTBUG-119708 Change-Id: I9020b7743cea65bbd92cadd5f570b7e38e999bd4 Reviewed-by: 🌴 Alexey Edelev 🌴 <alexey.edelev@qt.io>
2023-12-14 14:59:21 +00:00
if(write_location)
string(APPEND content "
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
if(_qt_imported_location${var_suffix})
Replace the impl of qt_configure_file with qt_configure_file_v2 The new version uses PARSE_ARGV which deals with semicolons better. Task-number: QTBUG-99238 Change-Id: Ie9276219400326a67ffa9cf5fc456ae7de0bbcd2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-01-11 13:02:13 +00:00
set_property(TARGET ${full_target} PROPERTY IMPORTED_LOCATION${property_suffix} \"$\{_qt_imported_location${var_suffix}}\")
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
endif()")
CMake: Export additional target info props for object libraries For some reason when building a user project in Release mode, when Qt was built with -DCMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug on MSVC, will result in linking of Debug object libraries into the user project. This does not happen in the same configuration on macOS. My guess is there is a difference in the logic on which configuration to choose between the platforms, perhaps based on package lookup order or something else. This was observed with qtgrpc's ProtobufWellKnownTypes_type_registration object library (which is only built on Windows as an object library). The issue can be fixed if we explicitly generate per-config imported location information for object libraries, just like we do for regular libraries. That way we'll have uniform build type information for all target types. Pick-to: 6.6 6.7 Fixes: QTBUG-119708 Change-Id: I9020b7743cea65bbd92cadd5f570b7e38e999bd4 Reviewed-by: 🌴 Alexey Edelev 🌴 <alexey.edelev@qt.io>
2023-12-14 14:59:21 +00:00
endif()
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
if(write_implib)
string(APPEND content "
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
if(_qt_imported_implib${var_suffix})
Replace the impl of qt_configure_file with qt_configure_file_v2 The new version uses PARSE_ARGV which deals with semicolons better. Task-number: QTBUG-99238 Change-Id: Ie9276219400326a67ffa9cf5fc456ae7de0bbcd2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-01-11 13:02:13 +00:00
set_property(TARGET ${full_target} PROPERTY IMPORTED_IMPLIB${property_suffix} \"$\{_qt_imported_implib${var_suffix}}\")
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
endif()")
endif()
if(write_soname)
string(APPEND content "
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
if(_qt_imported_soname${var_suffix})
Replace the impl of qt_configure_file with qt_configure_file_v2 The new version uses PARSE_ARGV which deals with semicolons better. Task-number: QTBUG-99238 Change-Id: Ie9276219400326a67ffa9cf5fc456ae7de0bbcd2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-01-11 13:02:13 +00:00
set_property(TARGET ${full_target} PROPERTY IMPORTED_SONAME${property_suffix} \"$\{_qt_imported_soname${var_suffix}}\")
CMake: Write link dependencies into AdditionalTargetInfo.cmake file When a shared library target has private dependencies to another shared library, they are exported by CMake into the target's IMPORTED_LINK_DEPENDENT_LIBRARIES_<CONFIG> property. This property then is read by the consuming project to determine which file paths need to be added to the -rpath-link linker option. Due to the simple logic that CMake uses to process this property, if the project CMAKE_BUILD_TYPE does not match the _<CONFIG> part of the property, the dependent libraries will not be added to -rpath-link, causing link failures. Make sure we explicitly set all the possible variants of the property in our custom Qt6FooAdditionalTargetInfo.cmake file, to ensure we always pick up the relevant dependent libraries for processing. In conjunction with 173164cd477211e574c0d04abef51aa0f4c3f78d and 1c287cea291d2a88770ff02771845d2a34e80964 in qtbase, this should hopefully avoid most -rpath-linking issues for QNX and Yocto builds. Pick-to: 6.8 Task-number: QTBUG-126727 Change-Id: I16a9cb5553d57e5ea3edc28cc2aab89c77f02a75 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-07-01 14:00:46 +00:00
endif()")
endif()
if(write_link_dependencies)
string(APPEND content "
if(_qt_imported_link_dependencies${var_suffix})
set_property(TARGET ${full_target} PROPERTY IMPORTED_LINK_DEPENDENT_LIBRARIES${property_suffix} \"$\{_qt_imported_link_dependencies${var_suffix}}\")
CMake: Export additional target info props for object libraries For some reason when building a user project in Release mode, when Qt was built with -DCMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug on MSVC, will result in linking of Debug object libraries into the user project. This does not happen in the same configuration on macOS. My guess is there is a difference in the logic on which configuration to choose between the platforms, perhaps based on package lookup order or something else. This was observed with qtgrpc's ProtobufWellKnownTypes_type_registration object library (which is only built on Windows as an object library). The issue can be fixed if we explicitly generate per-config imported location information for object libraries, just like we do for regular libraries. That way we'll have uniform build type information for all target types. Pick-to: 6.6 6.7 Fixes: QTBUG-119708 Change-Id: I9020b7743cea65bbd92cadd5f570b7e38e999bd4 Reviewed-by: 🌴 Alexey Edelev 🌴 <alexey.edelev@qt.io>
2023-12-14 14:59:21 +00:00
endif()")
endif()
if(write_objects)
string(APPEND content "
if(_qt_imported_objects${var_suffix})
set_property(TARGET ${full_target} PROPERTY IMPORTED_OBJECTS${property_suffix} \"$\{_qt_imported_objects${var_suffix}}\")
endif()")
string(APPEND content "
if(_qt_imported_clr${var_suffix})
set_property(TARGET ${full_target} PROPERTY IMPORTED_COMMON_LANGUAGE_RUNTIME${property_suffix} \"$\{_qt_imported_clr${var_suffix}}\")
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
endif()")
endif()
string(APPEND content "\n")
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
endforeach()
endforeach()
if(properties_retrieved)
string(APPEND content "
unset(_qt_imported_location)
unset(_qt_imported_location_default)
unset(_qt_imported_soname)
Fix build of Debug projects against debug-and-release non-prefix Qt Building a CMake project with CMAKE_BUILD_CONFIG=Debug was broken for non-prefix debug-and-release builds of Qt. In debug-and-release builds we set EXCLUDE_FROM_ALL on tools in the Debug configuration. In non-prefix builds we export(EXPORT) targets, and that also contains the non-existent Debug variants of the tools. In prefix builds, we install(EXPORT) instead, which only exports what is built and installed. Consequently, we now remove the DEBUG-related import information if the debug variant if the target binary does not exist. Pick-to: 6.2 Fixes: QTBUG-95027 Change-Id: I37766d5ab1e2795bcb91a348e7e72150e8a00f82 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 07:59:05 +00:00
unset(_qt_imported_soname_default)
CMake: Write link dependencies into AdditionalTargetInfo.cmake file When a shared library target has private dependencies to another shared library, they are exported by CMake into the target's IMPORTED_LINK_DEPENDENT_LIBRARIES_<CONFIG> property. This property then is read by the consuming project to determine which file paths need to be added to the -rpath-link linker option. Due to the simple logic that CMake uses to process this property, if the project CMAKE_BUILD_TYPE does not match the _<CONFIG> part of the property, the dependent libraries will not be added to -rpath-link, causing link failures. Make sure we explicitly set all the possible variants of the property in our custom Qt6FooAdditionalTargetInfo.cmake file, to ensure we always pick up the relevant dependent libraries for processing. In conjunction with 173164cd477211e574c0d04abef51aa0f4c3f78d and 1c287cea291d2a88770ff02771845d2a34e80964 in qtbase, this should hopefully avoid most -rpath-linking issues for QNX and Yocto builds. Pick-to: 6.8 Task-number: QTBUG-126727 Change-Id: I16a9cb5553d57e5ea3edc28cc2aab89c77f02a75 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-07-01 14:00:46 +00:00
unset(_qt_imported_link_dependencies)
unset(_qt_imported_link_dependencies_default)
CMake: Export additional target info props for object libraries For some reason when building a user project in Release mode, when Qt was built with -DCMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug on MSVC, will result in linking of Debug object libraries into the user project. This does not happen in the same configuration on macOS. My guess is there is a difference in the logic on which configuration to choose between the platforms, perhaps based on package lookup order or something else. This was observed with qtgrpc's ProtobufWellKnownTypes_type_registration object library (which is only built on Windows as an object library). The issue can be fixed if we explicitly generate per-config imported location information for object libraries, just like we do for regular libraries. That way we'll have uniform build type information for all target types. Pick-to: 6.6 6.7 Fixes: QTBUG-119708 Change-Id: I9020b7743cea65bbd92cadd5f570b7e38e999bd4 Reviewed-by: 🌴 Alexey Edelev 🌴 <alexey.edelev@qt.io>
2023-12-14 14:59:21 +00:00
unset(_qt_imported_objects)
unset(_qt_imported_objects_default)
unset(_qt_imported_clr)
unset(_qt_imported_clr_default)
Fix build of Debug projects against debug-and-release non-prefix Qt Building a CMake project with CMAKE_BUILD_CONFIG=Debug was broken for non-prefix debug-and-release builds of Qt. In debug-and-release builds we set EXCLUDE_FROM_ALL on tools in the Debug configuration. In non-prefix builds we export(EXPORT) targets, and that also contains the non-existent Debug variants of the tools. In prefix builds, we install(EXPORT) instead, which only exports what is built and installed. Consequently, we now remove the DEBUG-related import information if the debug variant if the target binary does not exist. Pick-to: 6.2 Fixes: QTBUG-95027 Change-Id: I37766d5ab1e2795bcb91a348e7e72150e8a00f82 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 07:59:05 +00:00
unset(_qt_imported_configs)")
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
endif()
CMake: Write proper *AdditionalTargetInfo file in debug-only build To provide the IMPORTED_LOCATION target property we must write the *AdditionalTargetInfo.cmake file for all debug-only builds, not only the ones containing a release configuration. Task-number: QTBUG-86893 Change-Id: I9ecd01483660f434a3f1ea12fa2af756cdcf9932 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-25 12:08:46 +00:00
qt_path_join(output_file "${arg_CONFIG_INSTALL_DIR}"
"${arg_EXPORT_NAME_PREFIX}AdditionalTargetInfo.cmake")
if(NOT IS_ABSOLUTE "${output_file}")
qt_path_join(output_file "${QT_BUILD_DIR}" "${output_file}")
endif()
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
qt_configure_file(OUTPUT "${output_file}" CONTENT "${content}")
qt_install(FILES "${output_file}" DESTINATION "${arg_CONFIG_INSTALL_DIR}")
endfunction()
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
function(qt_internal_export_modern_cmake_config_targets_file)
"Simplify" versionless targets Versionless targets in Qt6 are interface libraries that link the versioned libraries using the INTERFACE link type. This makes the linking chain more complicated than it can be. Also we miss some significant interface properties in the versionless targets comparing to the versioned targets. The new approach manually generates the versionless targets, instead of using CMake exports. For CMake versions < 3.18 we now create a copy of the versioned targets. The copy includes all the relevant INTERFACE properties from the versioned targets and imported locations for all configs. For CMake versions >= 3.18 we now create the versionless target ALIASes which should behave give the transparent access to the versioned targets. Using the QT_USE_OLD_VERSION_LESS_TARGETS flag you may force the behavor of the CMake versions <= 3.18 The change is partial workaround for QTBUG-86533. Task-number: QTBUG-114706 Change-Id: Iafadf6154eb4912df0697648c031fcc1cbde04e0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-01-24 15:12:19 +00:00
cmake_parse_arguments(arg
""
"EXPORT_NAME_PREFIX;CONFIG_BUILD_DIR;CONFIG_INSTALL_DIR"
"TARGETS"
${ARGN}
)
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
"Simplify" versionless targets Versionless targets in Qt6 are interface libraries that link the versioned libraries using the INTERFACE link type. This makes the linking chain more complicated than it can be. Also we miss some significant interface properties in the versionless targets comparing to the versioned targets. The new approach manually generates the versionless targets, instead of using CMake exports. For CMake versions < 3.18 we now create a copy of the versioned targets. The copy includes all the relevant INTERFACE properties from the versioned targets and imported locations for all configs. For CMake versions >= 3.18 we now create the versionless target ALIASes which should behave give the transparent access to the versioned targets. Using the QT_USE_OLD_VERSION_LESS_TARGETS flag you may force the behavor of the CMake versions <= 3.18 The change is partial workaround for QTBUG-86533. Task-number: QTBUG-114706 Change-Id: Iafadf6154eb4912df0697648c031fcc1cbde04e0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-01-24 15:12:19 +00:00
if("${arg_TARGETS}" STREQUAL "")
message(FATAL_ERROR "Target list is empty")
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
"Simplify" versionless targets Versionless targets in Qt6 are interface libraries that link the versioned libraries using the INTERFACE link type. This makes the linking chain more complicated than it can be. Also we miss some significant interface properties in the versionless targets comparing to the versioned targets. The new approach manually generates the versionless targets, instead of using CMake exports. For CMake versions < 3.18 we now create a copy of the versioned targets. The copy includes all the relevant INTERFACE properties from the versioned targets and imported locations for all configs. For CMake versions >= 3.18 we now create the versionless target ALIASes which should behave give the transparent access to the versioned targets. Using the QT_USE_OLD_VERSION_LESS_TARGETS flag you may force the behavor of the CMake versions <= 3.18 The change is partial workaround for QTBUG-86533. Task-number: QTBUG-114706 Change-Id: Iafadf6154eb4912df0697648c031fcc1cbde04e0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-01-24 15:12:19 +00:00
if("${arg_CONFIG_BUILD_DIR}" STREQUAL "")
message(FATAL_ERROR "CONFIG_BUILD_DIR is not specified")
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
"Simplify" versionless targets Versionless targets in Qt6 are interface libraries that link the versioned libraries using the INTERFACE link type. This makes the linking chain more complicated than it can be. Also we miss some significant interface properties in the versionless targets comparing to the versioned targets. The new approach manually generates the versionless targets, instead of using CMake exports. For CMake versions < 3.18 we now create a copy of the versioned targets. The copy includes all the relevant INTERFACE properties from the versioned targets and imported locations for all configs. For CMake versions >= 3.18 we now create the versionless target ALIASes which should behave give the transparent access to the versioned targets. Using the QT_USE_OLD_VERSION_LESS_TARGETS flag you may force the behavor of the CMake versions <= 3.18 The change is partial workaround for QTBUG-86533. Task-number: QTBUG-114706 Change-Id: Iafadf6154eb4912df0697648c031fcc1cbde04e0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-01-24 15:12:19 +00:00
if("${arg_CONFIG_INSTALL_DIR}" STREQUAL "")
message(FATAL_ERROR "CONFIG_INSTALL_DIR is not specified")
endif()
if("${arg_EXPORT_NAME_PREFIX}" STREQUAL "")
message(FATAL_ERROR "EXPORT_NAME_PREFIX is not specified")
endif()
set(versionless_targets ${arg_TARGETS})
# CMake versions < 3.18 compatibility code. Creates the mimics of the versioned libraries.
set(versionless_targets_export "${arg_CONFIG_BUILD_DIR}/${arg_EXPORT_NAME_PREFIX}VersionlessTargets.cmake")
configure_file("${QT_CMAKE_DIR}/QtVersionlessTargets.cmake.in"
"${versionless_targets_export}"
@ONLY
)
# CMake versions >= 3.18 code. Create the versionless ALIAS targets.
set(alias_export "${arg_CONFIG_BUILD_DIR}/${arg_EXPORT_NAME_PREFIX}VersionlessAliasTargets.cmake")
configure_file("${QT_CMAKE_DIR}/QtVersionlessAliasTargets.cmake.in"
"${alias_export}"
@ONLY
)
qt_install(FILES
"${alias_export}"
"${versionless_targets_export}"
DESTINATION "${arg_CONFIG_INSTALL_DIR}"
COMPONENT Devel
)
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()
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_create_tracepoints name tracepoints_file)
CMake: Implement configure -trace Task-number: QTBUG-85373 Change-Id: Ib9ac35ec98dd5b6c272f58f8a61a124d1d262ec0 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-24 19:05:05 +00:00
string(TOLOWER "${name}" provider_name)
string(PREPEND provider_name "qt")
set(header_filename "${provider_name}_tracepoints_p.h")
set(header_path "${CMAKE_CURRENT_BINARY_DIR}/${header_filename}")
Add CTF tracing backend Implement platform independent tracing backend in Common trace format. This allows tracing in platforms without own/existing backend and analysing all platforms with the same tooling. The backend is the basis for further work in application level profiling area. The backend is implemented as a plugin that is loaded immediately when the application starts in order to process all trace events. The backend avoids using Qt classes so that it doesn't generate trace events itself. Adds plumbing to configure the new backend. Modifies the tracegen and tracepointgen tools to support the new backend. Task-number: QTBUG-106399 Pick-to: 6.5 Change-Id: I80711be52d4d48e1acbc72edffbdf3f379fce52a Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
2022-10-24 08:30:56 +00:00
if(QT_FEATURE_lttng OR QT_FEATURE_etw OR QT_FEATURE_ctf)
CMake: Implement configure -trace Task-number: QTBUG-85373 Change-Id: Ib9ac35ec98dd5b6c272f58f8a61a124d1d262ec0 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-24 19:05:05 +00:00
set(source_path "${CMAKE_CURRENT_BINARY_DIR}/${provider_name}_tracepoints.cpp")
qt_configure_file(OUTPUT "${source_path}"
CONTENT "#define TRACEPOINT_CREATE_PROBES
#define TRACEPOINT_DEFINE
CMake: Fix generation of XXX_tracepoints.cpp The include directive was incorrectly written. This amends 5c092c2b401. Change-Id: Ia72ca3a5d5e1486ade4d71a764550d36979640f6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-10 14:17:16 +00:00
#include \"${header_filename}\"")
CMake: Implement configure -trace Task-number: QTBUG-85373 Change-Id: Ib9ac35ec98dd5b6c272f58f8a61a124d1d262ec0 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-24 19:05:05 +00:00
target_sources(${name} PRIVATE "${source_path}")
Trace: Make Q_TRACEPOINT public Allows sharing tracepoints between modules so that they can share one trace group. Pick-to: 6.5 Change-Id: I8de6da6beef02b34700cc2ecb1fad0e72a00b7e0 Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io> Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
2023-03-08 08:38:47 +00:00
target_compile_definitions(${name} PUBLIC Q_TRACEPOINT)
CMake: Implement configure -trace Task-number: QTBUG-85373 Change-Id: Ib9ac35ec98dd5b6c272f58f8a61a124d1d262ec0 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-24 19:05:05 +00:00
if(QT_FEATURE_lttng)
set(tracegen_arg "lttng")
target_link_libraries(${name} PRIVATE LTTng::UST)
elseif(QT_FEATURE_etw)
set(tracegen_arg "etw")
Add CTF tracing backend Implement platform independent tracing backend in Common trace format. This allows tracing in platforms without own/existing backend and analysing all platforms with the same tooling. The backend is the basis for further work in application level profiling area. The backend is implemented as a plugin that is loaded immediately when the application starts in order to process all trace events. The backend avoids using Qt classes so that it doesn't generate trace events itself. Adds plumbing to configure the new backend. Modifies the tracegen and tracepointgen tools to support the new backend. Task-number: QTBUG-106399 Pick-to: 6.5 Change-Id: I80711be52d4d48e1acbc72edffbdf3f379fce52a Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
2022-10-24 08:30:56 +00:00
elseif(QT_FEATURE_ctf)
set(tracegen_arg "ctf")
CMake: Implement configure -trace Task-number: QTBUG-85373 Change-Id: Ib9ac35ec98dd5b6c272f58f8a61a124d1d262ec0 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-24 19:05:05 +00:00
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
CMake: Use host variables instead of hardcoded directories 'QT_HOST_PATH' indicates that we use crosscompilation toolchain to build project. In this case 'Qt6Config.cmake' loads 'Qt6HostInfoConfig.cmake' from host QT_HOST_PATH, that defines correct paths to host tools. Replace hardcoded paths for host tools by paths recorded in Qt6HostInfoConfig.cmake. Correct conditions for QT_HOST_PATH, evaluate it explicitly as string, but not as boolean expression. Fixes: QTBUG-86557 Pick-to: 6.0 Change-Id: Ib52bbd32478051d019a932dcb1f735e2d4aacfbf Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-12-15 17:09:32 +00:00
if(NOT "${QT_HOST_PATH}" STREQUAL "")
Avoid using the PROJECT_VERSION_MAJOR as the HostInfo variable prefix Manage the HostInfo variable prefix the correct way. The prefix takes the HostInfo PROJECT_VERSION_MAJOR as the version specifier, which is not necessary is the same as the PROJECT_VERSION_MAJOR of the project that uses respective API. Instead of relying on the current PROJECT_VERSION, use the version info stored in HostInfo package and adjust the prefix accordingly. This will allow version mismatching between the project that uses API and HostInfo version. Change-Id: Idbaec1c7bb203448ceb0f15c9173ad3985c7112d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-03-17 17:55:27 +00:00
qt_internal_get_host_info_var_prefix(host_info_var_prefix)
CMake: Fix call to tracegen when cross-compiling tools We need to use the imported host tracegen target to generate files, not the one we're going to cross-build. This amends 5c092c2b401. Change-Id: Ib74dd2d87110383c31216872eb55bebf5d90df37 Reviewed-by: Samuli Piippo <samuli.piippo@qt.io>
2020-09-03 10:04:54 +00:00
qt_path_join(tracegen
"${QT_HOST_PATH}"
Avoid using the PROJECT_VERSION_MAJOR as the HostInfo variable prefix Manage the HostInfo variable prefix the correct way. The prefix takes the HostInfo PROJECT_VERSION_MAJOR as the version specifier, which is not necessary is the same as the PROJECT_VERSION_MAJOR of the project that uses respective API. Instead of relying on the current PROJECT_VERSION, use the version info stored in HostInfo package and adjust the prefix accordingly. This will allow version mismatching between the project that uses API and HostInfo version. Change-Id: Idbaec1c7bb203448ceb0f15c9173ad3985c7112d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-03-17 17:55:27 +00:00
"${${host_info_var_prefix}_LIBEXECDIR}"
CMake: Fix call to tracegen when cross-compiling tools We need to use the imported host tracegen target to generate files, not the one we're going to cross-build. This amends 5c092c2b401. Change-Id: Ib74dd2d87110383c31216872eb55bebf5d90df37 Reviewed-by: Samuli Piippo <samuli.piippo@qt.io>
2020-09-03 10:04:54 +00:00
"tracegen")
else()
set(tracegen "${QT_CMAKE_EXPORT_NAMESPACE}::tracegen")
endif()
CMake: Implement configure -trace Task-number: QTBUG-85373 Change-Id: Ib9ac35ec98dd5b6c272f58f8a61a124d1d262ec0 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-24 19:05:05 +00:00
get_filename_component(tracepoints_filepath "${tracepoints_file}" ABSOLUTE)
add_custom_command(OUTPUT "${header_path}"
CMake: Fix call to tracegen when cross-compiling tools We need to use the imported host tracegen target to generate files, not the one we're going to cross-build. This amends 5c092c2b401. Change-Id: Ib74dd2d87110383c31216872eb55bebf5d90df37 Reviewed-by: Samuli Piippo <samuli.piippo@qt.io>
2020-09-03 10:04:54 +00:00
COMMAND ${tracegen} ${tracegen_arg} "${tracepoints_filepath}" "${header_path}"
CMake: Implement configure -trace Task-number: QTBUG-85373 Change-Id: Ib9ac35ec98dd5b6c272f58f8a61a124d1d262ec0 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-24 19:05:05 +00:00
VERBATIM)
add_custom_target(${name}_tracepoints_header DEPENDS "${header_path}")
add_dependencies(${name} ${name}_tracepoints_header)
Add tracepointgen tool and convert qtgui to use it Allows automatically generating tracepoint files by scanning source files for instrumentation macros. This makes it easier to add tracepoint support to modules and also ensures that the tracepoint files do not get out of sync with the functions they are tracing. Q_TRACE_INSTRUMENT generates entry/exit tracespoints for a function it is set. Q_TRACE_PARAM_REPLACE is used to change a function parameter for these functions to convert it to supported parameter type. Q_TRACE_POINT can be used to create a standalone tracepoint. Q_TRACE_PREFIX can be used to add prefix for generated tracing backend for example to add includes for types used in the trace points.. Task-number: QTBUG-107238 Pick-to: 6.5 Change-Id: Ib395b80838434ceb72683dac0545ca20c4d09455 Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
2022-09-19 05:23:13 +00:00
else()
qt_configure_file(OUTPUT "${header_path}" CONTENT "#include <private/qtrace_p.h>\n")
endif()
endfunction()
function(qt_internal_generate_tracepoints name provider)
cmake_parse_arguments(arg "" "" "SOURCES" ${ARGN} )
set(provider_name ${provider})
string(PREPEND provider_name "qt")
set(tracepoint_filename "${provider_name}.tracepoints")
set(tracepoints_path "${CMAKE_CURRENT_BINARY_DIR}/${tracepoint_filename}")
set(header_filename "${provider_name}_tracepoints_p.h")
set(header_path "${CMAKE_CURRENT_BINARY_DIR}/${header_filename}")
Add CTF tracing backend Implement platform independent tracing backend in Common trace format. This allows tracing in platforms without own/existing backend and analysing all platforms with the same tooling. The backend is the basis for further work in application level profiling area. The backend is implemented as a plugin that is loaded immediately when the application starts in order to process all trace events. The backend avoids using Qt classes so that it doesn't generate trace events itself. Adds plumbing to configure the new backend. Modifies the tracegen and tracepointgen tools to support the new backend. Task-number: QTBUG-106399 Pick-to: 6.5 Change-Id: I80711be52d4d48e1acbc72edffbdf3f379fce52a Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
2022-10-24 08:30:56 +00:00
if(QT_FEATURE_lttng OR QT_FEATURE_etw OR QT_FEATURE_ctf)
Add tracepointgen tool and convert qtgui to use it Allows automatically generating tracepoint files by scanning source files for instrumentation macros. This makes it easier to add tracepoint support to modules and also ensures that the tracepoint files do not get out of sync with the functions they are tracing. Q_TRACE_INSTRUMENT generates entry/exit tracespoints for a function it is set. Q_TRACE_PARAM_REPLACE is used to change a function parameter for these functions to convert it to supported parameter type. Q_TRACE_POINT can be used to create a standalone tracepoint. Q_TRACE_PREFIX can be used to add prefix for generated tracing backend for example to add includes for types used in the trace points.. Task-number: QTBUG-107238 Pick-to: 6.5 Change-Id: Ib395b80838434ceb72683dac0545ca20c4d09455 Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
2022-09-19 05:23:13 +00:00
set(absolute_file_paths "")
foreach(file IN LISTS arg_SOURCES)
get_filename_component(absolute_file ${file} ABSOLUTE)
list(APPEND absolute_file_paths ${absolute_file})
endforeach()
if(NOT "${QT_HOST_PATH}" STREQUAL "")
Avoid using the PROJECT_VERSION_MAJOR as the HostInfo variable prefix Manage the HostInfo variable prefix the correct way. The prefix takes the HostInfo PROJECT_VERSION_MAJOR as the version specifier, which is not necessary is the same as the PROJECT_VERSION_MAJOR of the project that uses respective API. Instead of relying on the current PROJECT_VERSION, use the version info stored in HostInfo package and adjust the prefix accordingly. This will allow version mismatching between the project that uses API and HostInfo version. Change-Id: Idbaec1c7bb203448ceb0f15c9173ad3985c7112d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-03-17 17:55:27 +00:00
qt_internal_get_host_info_var_prefix(host_info_var_prefix)
Add tracepointgen tool and convert qtgui to use it Allows automatically generating tracepoint files by scanning source files for instrumentation macros. This makes it easier to add tracepoint support to modules and also ensures that the tracepoint files do not get out of sync with the functions they are tracing. Q_TRACE_INSTRUMENT generates entry/exit tracespoints for a function it is set. Q_TRACE_PARAM_REPLACE is used to change a function parameter for these functions to convert it to supported parameter type. Q_TRACE_POINT can be used to create a standalone tracepoint. Q_TRACE_PREFIX can be used to add prefix for generated tracing backend for example to add includes for types used in the trace points.. Task-number: QTBUG-107238 Pick-to: 6.5 Change-Id: Ib395b80838434ceb72683dac0545ca20c4d09455 Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
2022-09-19 05:23:13 +00:00
qt_path_join(tracepointgen
"${QT_HOST_PATH}"
Avoid using the PROJECT_VERSION_MAJOR as the HostInfo variable prefix Manage the HostInfo variable prefix the correct way. The prefix takes the HostInfo PROJECT_VERSION_MAJOR as the version specifier, which is not necessary is the same as the PROJECT_VERSION_MAJOR of the project that uses respective API. Instead of relying on the current PROJECT_VERSION, use the version info stored in HostInfo package and adjust the prefix accordingly. This will allow version mismatching between the project that uses API and HostInfo version. Change-Id: Idbaec1c7bb203448ceb0f15c9173ad3985c7112d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-03-17 17:55:27 +00:00
"${${host_info_var_prefix}_LIBEXECDIR}"
Add tracepointgen tool and convert qtgui to use it Allows automatically generating tracepoint files by scanning source files for instrumentation macros. This makes it easier to add tracepoint support to modules and also ensures that the tracepoint files do not get out of sync with the functions they are tracing. Q_TRACE_INSTRUMENT generates entry/exit tracespoints for a function it is set. Q_TRACE_PARAM_REPLACE is used to change a function parameter for these functions to convert it to supported parameter type. Q_TRACE_POINT can be used to create a standalone tracepoint. Q_TRACE_PREFIX can be used to add prefix for generated tracing backend for example to add includes for types used in the trace points.. Task-number: QTBUG-107238 Pick-to: 6.5 Change-Id: Ib395b80838434ceb72683dac0545ca20c4d09455 Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
2022-09-19 05:23:13 +00:00
"tracepointgen")
else()
set(tracepointgen "${QT_CMAKE_EXPORT_NAMESPACE}::tracepointgen")
endif()
add_custom_command(OUTPUT "${tracepoints_path}"
Tracepointgen: Parse metadata from include files The tracepointgen tool needs to know the enumeration/flag names and values in order to generate metadata for the tracepoints in order to pass this information when tracing. Currently the metadata needs to be provided to the tracepointgen by hand. This implements metadata parsing from header files. Task-number: QTBUG-110598 Pick-to: 6.5 Change-Id: Ibb2cc6e724fd2defca4e301af2285b0fdbe8e7f7 Reviewed-by: Antti Määttä <antti.maatta@qt.io>
2023-01-27 06:06:54 +00:00
COMMAND ${tracepointgen} ${provider_name} "${tracepoints_path}" "I$<JOIN:$<TARGET_PROPERTY:${name},INCLUDE_DIRECTORIES>,;>" ${absolute_file_paths}
Add tracepointgen tool and convert qtgui to use it Allows automatically generating tracepoint files by scanning source files for instrumentation macros. This makes it easier to add tracepoint support to modules and also ensures that the tracepoint files do not get out of sync with the functions they are tracing. Q_TRACE_INSTRUMENT generates entry/exit tracespoints for a function it is set. Q_TRACE_PARAM_REPLACE is used to change a function parameter for these functions to convert it to supported parameter type. Q_TRACE_POINT can be used to create a standalone tracepoint. Q_TRACE_PREFIX can be used to add prefix for generated tracing backend for example to add includes for types used in the trace points.. Task-number: QTBUG-107238 Pick-to: 6.5 Change-Id: Ib395b80838434ceb72683dac0545ca20c4d09455 Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
2022-09-19 05:23:13 +00:00
DEPENDS ${absolute_file_paths}
VERBATIM)
add_custom_target(${name}_${provider_name}_tracepoints_file DEPENDS "${tracepoints_path}")
add_dependencies(${name} ${name}_${provider_name}_tracepoints_file)
set(source_path "${CMAKE_CURRENT_BINARY_DIR}/${provider_name}_tracepoints.cpp")
qt_configure_file(OUTPUT "${source_path}"
CONTENT "#define TRACEPOINT_CREATE_PROBES
#define TRACEPOINT_DEFINE
#include \"${header_filename}\"")
target_sources(${name} PRIVATE "${source_path}")
Trace: Make Q_TRACEPOINT public Allows sharing tracepoints between modules so that they can share one trace group. Pick-to: 6.5 Change-Id: I8de6da6beef02b34700cc2ecb1fad0e72a00b7e0 Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io> Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
2023-03-08 08:38:47 +00:00
target_compile_definitions(${name} PUBLIC Q_TRACEPOINT)
Add tracepointgen tool and convert qtgui to use it Allows automatically generating tracepoint files by scanning source files for instrumentation macros. This makes it easier to add tracepoint support to modules and also ensures that the tracepoint files do not get out of sync with the functions they are tracing. Q_TRACE_INSTRUMENT generates entry/exit tracespoints for a function it is set. Q_TRACE_PARAM_REPLACE is used to change a function parameter for these functions to convert it to supported parameter type. Q_TRACE_POINT can be used to create a standalone tracepoint. Q_TRACE_PREFIX can be used to add prefix for generated tracing backend for example to add includes for types used in the trace points.. Task-number: QTBUG-107238 Pick-to: 6.5 Change-Id: Ib395b80838434ceb72683dac0545ca20c4d09455 Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
2022-09-19 05:23:13 +00:00
if(QT_FEATURE_lttng)
set(tracegen_arg "lttng")
target_link_libraries(${name} PRIVATE LTTng::UST)
elseif(QT_FEATURE_etw)
set(tracegen_arg "etw")
Add CTF tracing backend Implement platform independent tracing backend in Common trace format. This allows tracing in platforms without own/existing backend and analysing all platforms with the same tooling. The backend is the basis for further work in application level profiling area. The backend is implemented as a plugin that is loaded immediately when the application starts in order to process all trace events. The backend avoids using Qt classes so that it doesn't generate trace events itself. Adds plumbing to configure the new backend. Modifies the tracegen and tracepointgen tools to support the new backend. Task-number: QTBUG-106399 Pick-to: 6.5 Change-Id: I80711be52d4d48e1acbc72edffbdf3f379fce52a Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
2022-10-24 08:30:56 +00:00
elseif(QT_FEATURE_ctf)
set(tracegen_arg "ctf")
Add tracepointgen tool and convert qtgui to use it Allows automatically generating tracepoint files by scanning source files for instrumentation macros. This makes it easier to add tracepoint support to modules and also ensures that the tracepoint files do not get out of sync with the functions they are tracing. Q_TRACE_INSTRUMENT generates entry/exit tracespoints for a function it is set. Q_TRACE_PARAM_REPLACE is used to change a function parameter for these functions to convert it to supported parameter type. Q_TRACE_POINT can be used to create a standalone tracepoint. Q_TRACE_PREFIX can be used to add prefix for generated tracing backend for example to add includes for types used in the trace points.. Task-number: QTBUG-107238 Pick-to: 6.5 Change-Id: Ib395b80838434ceb72683dac0545ca20c4d09455 Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
2022-09-19 05:23:13 +00:00
endif()
if(NOT "${QT_HOST_PATH}" STREQUAL "")
Avoid using the PROJECT_VERSION_MAJOR as the HostInfo variable prefix Manage the HostInfo variable prefix the correct way. The prefix takes the HostInfo PROJECT_VERSION_MAJOR as the version specifier, which is not necessary is the same as the PROJECT_VERSION_MAJOR of the project that uses respective API. Instead of relying on the current PROJECT_VERSION, use the version info stored in HostInfo package and adjust the prefix accordingly. This will allow version mismatching between the project that uses API and HostInfo version. Change-Id: Idbaec1c7bb203448ceb0f15c9173ad3985c7112d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-03-17 17:55:27 +00:00
qt_internal_get_host_info_var_prefix(host_info_var_prefix)
Add tracepointgen tool and convert qtgui to use it Allows automatically generating tracepoint files by scanning source files for instrumentation macros. This makes it easier to add tracepoint support to modules and also ensures that the tracepoint files do not get out of sync with the functions they are tracing. Q_TRACE_INSTRUMENT generates entry/exit tracespoints for a function it is set. Q_TRACE_PARAM_REPLACE is used to change a function parameter for these functions to convert it to supported parameter type. Q_TRACE_POINT can be used to create a standalone tracepoint. Q_TRACE_PREFIX can be used to add prefix for generated tracing backend for example to add includes for types used in the trace points.. Task-number: QTBUG-107238 Pick-to: 6.5 Change-Id: Ib395b80838434ceb72683dac0545ca20c4d09455 Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
2022-09-19 05:23:13 +00:00
qt_path_join(tracegen
"${QT_HOST_PATH}"
Avoid using the PROJECT_VERSION_MAJOR as the HostInfo variable prefix Manage the HostInfo variable prefix the correct way. The prefix takes the HostInfo PROJECT_VERSION_MAJOR as the version specifier, which is not necessary is the same as the PROJECT_VERSION_MAJOR of the project that uses respective API. Instead of relying on the current PROJECT_VERSION, use the version info stored in HostInfo package and adjust the prefix accordingly. This will allow version mismatching between the project that uses API and HostInfo version. Change-Id: Idbaec1c7bb203448ceb0f15c9173ad3985c7112d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-03-17 17:55:27 +00:00
"${${host_info_var_prefix}_LIBEXECDIR}"
Add tracepointgen tool and convert qtgui to use it Allows automatically generating tracepoint files by scanning source files for instrumentation macros. This makes it easier to add tracepoint support to modules and also ensures that the tracepoint files do not get out of sync with the functions they are tracing. Q_TRACE_INSTRUMENT generates entry/exit tracespoints for a function it is set. Q_TRACE_PARAM_REPLACE is used to change a function parameter for these functions to convert it to supported parameter type. Q_TRACE_POINT can be used to create a standalone tracepoint. Q_TRACE_PREFIX can be used to add prefix for generated tracing backend for example to add includes for types used in the trace points.. Task-number: QTBUG-107238 Pick-to: 6.5 Change-Id: Ib395b80838434ceb72683dac0545ca20c4d09455 Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
2022-09-19 05:23:13 +00:00
"tracegen")
else()
set(tracegen "${QT_CMAKE_EXPORT_NAMESPACE}::tracegen")
endif()
get_filename_component(tracepoints_filepath "${tracepoints_path}" ABSOLUTE)
add_custom_command(OUTPUT "${header_path}"
COMMAND ${tracegen} ${tracegen_arg} "${tracepoints_filepath}" "${header_path}"
DEPENDS "${tracepoints_path}"
VERBATIM)
add_custom_target(${name}_${provider_name}_tracepoints_header DEPENDS "${header_path}")
add_dependencies(${name} ${name}_${provider_name}_tracepoints_header)
CMake: Implement configure -trace Task-number: QTBUG-85373 Change-Id: Ib9ac35ec98dd5b6c272f58f8a61a124d1d262ec0 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-24 19:05:05 +00:00
else()
qt_configure_file(OUTPUT "${header_path}" CONTENT "#include <private/qtrace_p.h>\n")
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endfunction()
CMake: Install PDB debug info for MSVC builds Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-09-29 20:07:33 +00:00
function(qt_internal_set_compile_pdb_names target)
if(MSVC)
get_target_property(target_type ${target} TYPE)
Install MSVC debug information for resource object libraries Building against a static debug MSVC Qt produced LNK4099 warnings (PDB was not found with object file). This was because we did not install the .pdb files for the object libraries that are created for Qt resources. Now, these .pdb files are named like the object library targets and are installed next to the object files. Pick-to: 6.2 Fixes: QTBUG-97699 Change-Id: I7e23f8392b7ac657be1d2fb3b33e051ae2e4d407 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-11-29 20:18:43 +00:00
if(target_type STREQUAL "STATIC_LIBRARY" OR target_type STREQUAL "OBJECT_LIBRARY")
CMake: set correct COMPILE_PDB_NAME for static libraries Output names of static libraries might be different from target names. For example, the library name of Qt6::DeviceDiscoverySupportPrivate is "Qt6DeviceDiscoverySupport.lib", and the library name of Qt6::QTlsBackendCertOnlyPlugin is "qcertonlybackend.lib". This commit make pdb files names consistent with the library names. And make sure we have set correct OUTPUT_NAME property before calling qt_set_common_target_properties()/qt_internal_set_compile_pdb_names(). Change-Id: Idb3cacd7a46a4f298fd584b927b5d726956faea8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-04-30 15:38:02 +00:00
get_target_property(output_name ${target} OUTPUT_NAME)
if(NOT output_name)
set(output_name "${INSTALL_CMAKE_NAMESPACE}${target}")
endif()
set_target_properties(${target} PROPERTIES COMPILE_PDB_NAME "${output_name}")
set_target_properties(${target} PROPERTIES COMPILE_PDB_NAME_DEBUG "${output_name}d")
CMake: Install PDB debug info for MSVC builds Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-09-29 20:07:33 +00:00
endif()
endif()
endfunction()
# Installs pdb files for given target into the specified install dir.
#
# MSVC generates 2 types of pdb files:
# - compile-time generated pdb files (compile flag /Zi + /Fd<pdb_name>)
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
# - link-time generated pdb files (link flag /debug + /PDB:<pdb_name>)
CMake: Install PDB debug info for MSVC builds Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-09-29 20:07:33 +00:00
#
# CMake allows changing the names of each of those pdb file types by setting
# the COMPILE_PDB_NAME_<CONFIG> and PDB_NAME_<CONFIG> properties. If they are
# left empty, CMake will compute the default names itself (or rather in certain cases
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
# leave it up to the compiler), without actually setting the property values.
CMake: Install PDB debug info for MSVC builds Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-09-29 20:07:33 +00:00
#
# For installation purposes, CMake only provides a generator expression to the
# link time pdb file path, not the compile path one, which means we have to compute the
# path to the compile path pdb files ourselves.
# See https://gitlab.kitware.com/cmake/cmake/-/issues/18393 for details.
#
# For shared libraries and executables, we install the linker provided pdb file via the
# TARGET_PDB_FILE generator expression.
#
# For static libraries there is no linker invocation, so we need to install the compile
# time pdb file. We query the ARCHIVE_OUTPUT_DIRECTORY property of the target to get the
# path to the pdb file, and reconstruct the file name. We use a generator expression
# to append a possible debug suffix, in order to allow installation of all Release and
# Debug pdb files when using Ninja Multi-Config.
function(qt_internal_install_pdb_files target install_dir_path)
if(MSVC)
get_target_property(target_type ${target} TYPE)
CMake: Install pdb files to proper directories in multi-config build In multi-config build, for different configs, the pdb files of EXEs should have different installation directories. For example, when CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug, <build_dir>/bin/moc.pdb will be installed to <install_dir>/bin/moc.pdb. <build_dir>/bin/Debug/moc.pdb should be installed to <install_dir>/bin/Debug/moc.pdb, not <install_dir>/bin/moc.pdb. Fixes: QTBUG-88268 Change-Id: Idc7c92ca8d44bb81d990656af2b309306a4f5c6b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-13 09:27:12 +00:00
if(target_type STREQUAL "EXECUTABLE")
qt_get_cmake_configurations(cmake_configs)
list(LENGTH cmake_configs all_configs_count)
list(GET cmake_configs 0 first_config)
foreach(cmake_config ${cmake_configs})
set(suffix "")
if(all_configs_count GREATER 1 AND NOT cmake_config STREQUAL first_config)
set(suffix "/${cmake_config}")
endif()
qt_install(FILES "$<TARGET_PDB_FILE:${target}>"
CONFIGURATIONS ${cmake_config}
DESTINATION "${install_dir_path}${suffix}"
OPTIONAL)
endforeach()
elseif(target_type STREQUAL "SHARED_LIBRARY"
CMake: Install PDB debug info for MSVC builds Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-09-29 20:07:33 +00:00
OR target_type STREQUAL "MODULE_LIBRARY")
qt_install(FILES "$<TARGET_PDB_FILE:${target}>"
DESTINATION "${install_dir_path}"
OPTIONAL)
elseif(target_type STREQUAL "STATIC_LIBRARY")
get_target_property(lib_dir "${target}" ARCHIVE_OUTPUT_DIRECTORY)
if(NOT lib_dir)
message(FATAL_ERROR
"Can't install pdb file for static library ${target}. "
"The ARCHIVE_OUTPUT_DIRECTORY path is not known.")
endif()
CMake: set correct COMPILE_PDB_NAME for static libraries Output names of static libraries might be different from target names. For example, the library name of Qt6::DeviceDiscoverySupportPrivate is "Qt6DeviceDiscoverySupport.lib", and the library name of Qt6::QTlsBackendCertOnlyPlugin is "qcertonlybackend.lib". This commit make pdb files names consistent with the library names. And make sure we have set correct OUTPUT_NAME property before calling qt_set_common_target_properties()/qt_internal_set_compile_pdb_names(). Change-Id: Idb3cacd7a46a4f298fd584b927b5d726956faea8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-04-30 15:38:02 +00:00
get_target_property(pdb_name "${target}" COMPILE_PDB_NAME)
qt_path_join(compile_time_pdb_file_path
"${lib_dir}" "${pdb_name}$<$<CONFIG:Debug>:d>.pdb")
CMake: Install PDB debug info for MSVC builds Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-09-29 20:07:33 +00:00
qt_install(FILES "${compile_time_pdb_file_path}"
DESTINATION "${install_dir_path}" OPTIONAL)
Install MSVC debug information for resource object libraries Building against a static debug MSVC Qt produced LNK4099 warnings (PDB was not found with object file). This was because we did not install the .pdb files for the object libraries that are created for Qt resources. Now, these .pdb files are named like the object library targets and are installed next to the object files. Pick-to: 6.2 Fixes: QTBUG-97699 Change-Id: I7e23f8392b7ac657be1d2fb3b33e051ae2e4d407 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-11-29 20:18:43 +00:00
elseif(target_type STREQUAL "OBJECT_LIBRARY")
get_target_property(pdb_dir "${target}" COMPILE_PDB_OUTPUT_DIRECTORY)
if(NOT pdb_dir)
get_target_property(pdb_dir "${target}" BINARY_DIR)
if(QT_GENERATOR_IS_MULTI_CONFIG)
qt_path_join(pdb_dir "${pdb_dir}" "$<CONFIG>")
endif()
endif()
CMake: set correct COMPILE_PDB_NAME for static libraries Output names of static libraries might be different from target names. For example, the library name of Qt6::DeviceDiscoverySupportPrivate is "Qt6DeviceDiscoverySupport.lib", and the library name of Qt6::QTlsBackendCertOnlyPlugin is "qcertonlybackend.lib". This commit make pdb files names consistent with the library names. And make sure we have set correct OUTPUT_NAME property before calling qt_set_common_target_properties()/qt_internal_set_compile_pdb_names(). Change-Id: Idb3cacd7a46a4f298fd584b927b5d726956faea8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-04-30 15:38:02 +00:00
get_target_property(pdb_name "${target}" COMPILE_PDB_NAME)
qt_path_join(compile_time_pdb_file_path
"${pdb_dir}" "${pdb_name}$<$<CONFIG:Debug>:d>.pdb")
Install MSVC debug information for resource object libraries Building against a static debug MSVC Qt produced LNK4099 warnings (PDB was not found with object file). This was because we did not install the .pdb files for the object libraries that are created for Qt resources. Now, these .pdb files are named like the object library targets and are installed next to the object files. Pick-to: 6.2 Fixes: QTBUG-97699 Change-Id: I7e23f8392b7ac657be1d2fb3b33e051ae2e4d407 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-11-29 20:18:43 +00:00
qt_install(FILES "${compile_time_pdb_file_path}"
DESTINATION "${install_dir_path}" OPTIONAL)
CMake: Install PDB debug info for MSVC builds Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-09-29 20:07:33 +00:00
endif()
endif()
endfunction()
CMake: Fix building multi-arch universal macOS Qt Use the same approach we use for iOS, which is to set multiple CMAKE_OSX_ARCHITECTURES values and let the clang front end deal with lipo-ing the final libraries. For now, Qt can be configured to build universal macOS libraries by passing 2 architectures to CMake, either via: -DCMAKE_OSX_ARCHITECTURES="x86_64;arm64" or -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" Currently we recommend specifying the intel x86_64 arch as the first one, to get an intel slice configuration that is comparable to a non-universal intel build. Specifying the arm64 slice first could pessimize optimizations and reduce the feature set for the intel slice due to the limitation that we run configure tests only once. The first specified architecture is the one used to do all the configure tests. It 'mostly' defines the common feature set of both architecture slices, with the excepion of some special handling for sse2 and neon instructions. In the future we might want to run at least the Qt architecture config test for all specified architectures, so that we can extract all the supported sub-arches and instruction sets in a reliable way. For now, we use the same sse2 hack as for iOS simulator_and_device builds, otherwise QtGui fails to link due to missing qt_memfill32_sse2 and other symbols. The hack is somewhat augmented to ensure that reconfiguration still succeeds (same issue happened with iOS). Previously the sse2 feature condition was broken due to force setting the feature to be ON. Now the condition also checks for a special QT_FORCE_FEATURE_sse2 variable which we set internally. Note that we shouldn't build for arm64e, because the binaries get killed when running on AS with the following message: kernel: exec_mach_imgact: not running binary built against preview arm64e ABI. Aslo, by default, we disable the arm64 slice for qt sql plugins, mostly because the CI provisioned sql libraries that we depend on only contain x86_64 slices, and trying to build the sql plugins for both slices will fail with linker errors. This behavior can be disabled for all targets marked by qt_internal_force_macos_intel_arch, by setting the QT_FORCE_MACOS_ALL_ARCHES CMake option to ON. To disble it per-target one can set QT_FORCE_MACOS_ALL_ARCHES_${target} to ON. Task-number: QTBUG-85447 Change-Id: Iccb5dfcc1a21a8a8292bd3817df0ea46c3445f75 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-03-24 15:03:35 +00:00
# Certain targets might have dependencies on libraries that don't have an Apple Silicon arm64
# slice. When doing a universal macOS build, force those targets to be built only for the
# Intel x86_64 arch.
# This behavior can be disabled for all targets by setting the QT_FORCE_MACOS_ALL_ARCHES cache
# variable to TRUE or by setting the target specific cache variable
# QT_FORCE_MACOS_ALL_ARCHES_${target} to TRUE.
#
# TODO: Ideally we'd use something like _apple_resolve_supported_archs_for_sdk_from_system_lib
# from CMake's codebase to parse which architectures are available in a library, but it's
# not straightforward to extract the library absolute file path from a CMake target. Furthermore
# Apple started using a built-in dynamic linker cache of all system-provided libraries as per
# https://gitlab.kitware.com/cmake/cmake/-/issues/20863
# so if the target is a library in the dynamic cache, that might further complicate how to get
# the list of arches in it.
function(qt_internal_force_macos_intel_arch target)
if(MACOS AND QT_IS_MACOS_UNIVERSAL AND NOT QT_FORCE_MACOS_ALL_ARCHES
AND NOT QT_FORCE_MACOS_ALL_ARCHES_${target})
set(arches "x86_64")
set_target_properties(${target} PROPERTIES OSX_ARCHITECTURES "${arches}")
endif()
endfunction()
CMake: Allow enabling Apple app extension API in other repos It's needed in qtconnectivity, but currently the qt_disable_apple_app_extension_api_only function is defined in QtInternalTargets.cmake which is loaded only in qtbase. Move the function to cmake/QtTargetHelpers.cmake. Amends e189126f1ae1d2fa2ad0f95ee2c4aa72c770a97b Pick-to: 6.1 Change-Id: Ia2470e48a91385239394368780f5bbb223000113 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-22 07:55:55 +00:00
function(qt_disable_apple_app_extension_api_only target)
set_target_properties("${target}" PROPERTIES QT_NO_APP_EXTENSION_ONLY_API TRUE)
endfunction()
Do not use qt_internal_module_info for non-module targets The qt_internal_module_info function suppose to provide the information only about the Qt modules. Avoid using it for the tool and extra package dependencies, since some targets do not always exist, when function is called. Add the qt_internal_qtfy_target function to make the prefixed target names. Change-Id: Ifa8c61064d9c6c430889f00a4ead304029da711b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-28 15:24:30 +00:00
# Common function to add Qt prefixes to the target name
function(qt_internal_qtfy_target out_var target)
set(${out_var} "Qt${target}" PARENT_SCOPE)
set(${out_var}_versioned "Qt${PROJECT_VERSION_MAJOR}${target}" PARENT_SCOPE)
endfunction()
CMake: Place internal apps in the correct output directory In a -debug-and-release build, apps were placed under bin/Release rather than just bin. Apply the logic we use for tools for apps as well. Rename and move the common functions into QtTargetHelpers.cmake. Pick-to: 6.2 Fixes: QTBUG-95028 Change-Id: I5a9082ea50c9238c8fcf0c6dd099708fbc571bf8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-07 14:04:17 +00:00
function(qt_internal_get_main_cmake_configuration out_var)
if(CMAKE_BUILD_TYPE)
set(config "${CMAKE_BUILD_TYPE}")
elseif(QT_MULTI_CONFIG_FIRST_CONFIG)
set(config "${QT_MULTI_CONFIG_FIRST_CONFIG}")
endif()
set("${out_var}" "${config}" PARENT_SCOPE)
endfunction()
function(qt_internal_get_upper_case_main_cmake_configuration out_var)
qt_internal_get_main_cmake_configuration("${out_var}")
string(TOUPPER "${${out_var}}" upper_config)
set("${out_var}" "${upper_config}" PARENT_SCOPE)
endfunction()
function(qt_internal_adjust_main_config_runtime_output_dir target output_dir)
# When building Qt with multiple configurations, place the main configuration executable
# directly in ${output_dir}, rather than a ${output_dir}/<CONFIG> subdirectory.
qt_internal_get_upper_case_main_cmake_configuration(main_cmake_configuration)
set_target_properties("${target}" PROPERTIES
RUNTIME_OUTPUT_DIRECTORY_${main_cmake_configuration} "${output_dir}"
)
endfunction()
CMake: Don't propagate -fapplication-extension to user projects Both the compiler and linker -fapplication-extension flag should only be applied when building Qt's libraries (not executables). It's up to the user project whether their code will be restricted with application-extension-only APIs. In qmake that can be achieved by adding to the qmake project CONFIG += app_extension_api_only In CMake it can be achieved by either adding the compiler and link flags in the project directly (using target_X_options) or by setting the appropriate setting in the Xcode project when using the Xcode generator. Amends e189126f1ae1d2fa2ad0f95ee2c4aa72c770a97b Pick-to: 6.2 Task-number: QTBUG-95199 Change-Id: Ie7a764d460a89c7650391abff0fcc5abfcabef64 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-15 11:04:15 +00:00
# Marks a target with a property that it is a library (shared or static) which was built using the
# internal Qt API (qt_internal_add_module, qt_internal_add_plugin, etc) as opposed to it being
# a user project library (qt_add_library, qt_add_plugin, etc).
#
# Needed to allow selectively applying certain flags via PlatformXInternal targets.
function(qt_internal_mark_as_internal_library target)
set_target_properties(${target} PROPERTIES _qt_is_internal_library TRUE)
CMake: Export the internal library and target properties Will be used in a future commit to do target filtering. Pick-to: 6.8 Change-Id: Iaf7039ff456ca11d94c44c6e12f63408d2aaa484 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-07-02 13:44:02 +00:00
set_property(TARGET "${target}" APPEND PROPERTY EXPORT_PROPERTIES "_qt_is_internal_library")
Fix CMP0099 impact - disallow propagating internal linker options CMP0099 changes the way of LINK_ONLY genex works. With CMP0099 set to OLD LINK_ONLY genex only links the exact library binary/archive without propagating other interface options from the target. This feature was exploited by PlatformXInternal targets to avoid propagating of their linker options. Nowadays when CMP0099 is forced to NEW by Qt scripts, including user-facing, we cannot rely on LINK_ONLY genex. Introduce _qt_is_internal_target property that is set for all Qt executables and explicitly limits the propagation of the linker options from PlatformXInternal targets. Pick-to: 6.5 6.6 Fixes: QTBUG-113641 Change-Id: I3a0ecddb65886e435073feb24c1b47035130ba70 Reviewed-by: Alexandru Croitor (OOO) <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-05-22 14:02:44 +00:00
qt_internal_mark_as_internal_target(${target})
endfunction()
# Marks a target with a property that it was built using the internal Qt API (qt_internal_*) as
# opposed to it being a user project library or executable(qt_add_*, etc).
#
# Needed to allow selectively applying certain flags via PlatformXInternal targets.
function(qt_internal_mark_as_internal_target target)
set_target_properties(${target} PROPERTIES _qt_is_internal_target TRUE)
CMake: Export the internal library and target properties Will be used in a future commit to do target filtering. Pick-to: 6.8 Change-Id: Iaf7039ff456ca11d94c44c6e12f63408d2aaa484 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-07-02 13:44:02 +00:00
set_property(TARGET "${target}" APPEND PROPERTY EXPORT_PROPERTIES "_qt_is_internal_target")
CMake: Don't propagate -fapplication-extension to user projects Both the compiler and linker -fapplication-extension flag should only be applied when building Qt's libraries (not executables). It's up to the user project whether their code will be restricted with application-extension-only APIs. In qmake that can be achieved by adding to the qmake project CONFIG += app_extension_api_only In CMake it can be achieved by either adding the compiler and link flags in the project directly (using target_X_options) or by setting the appropriate setting in the Xcode project when using the Xcode generator. Amends e189126f1ae1d2fa2ad0f95ee2c4aa72c770a97b Pick-to: 6.2 Task-number: QTBUG-95199 Change-Id: Ie7a764d460a89c7650391abff0fcc5abfcabef64 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-15 11:04:15 +00:00
endfunction()
CMake: Apply bitcode flags to internal plugin object lib initializers All internal libraries, plugins, object libraries (resources, plugin initializers) need to be built with bitcode flags when targeting iOS. Internal here means all libraries added by qt_internal_add_X functions or associated with internal libraries. We didn't do that for plugin initializers, which were added not too long ago. Extract the logic that links to Qt::PlatformModuleInternal into a separate function to be used for object libraries. Use it for resources and plugin initializers. It will also be used in qtdeclarative for qml plugin initializers. Pick-to: 6.2 Task-number: QTBUG-95208 Change-Id: I366996078f5e9d1c2d2797f6b81c522ee99529e3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-15 11:41:15 +00:00
CMake: Work around AUTOUIC Ninja Multi-Config issue with EP examples AUTOUIC doesn't handle relative paths to .ui files in parent directories when using Ninja Multi-Config. The designer tool in qttools has such a ui file. This leads to the following error when trying to build qttools together with examples as ExternalProjects and Ninja Multi-Config: ninja: error: 'src/designer/src/designer/designer_autogen/ include_Debug/ui_preferencesdialog.h', needed by 'src/designer/src/designer/designer_autogen:Debug', missing and no known rule to make it Until cmake is fixed, we can work around the issue by not adding designer as a dependency when building EP examples, because no example tries to use the app. We can't exclude all apps from example dependencies because some modules use qt_internal_add_app for tools as well, which are called from public CMake API and also examples. An example of this is qtapplicationmanager. Given that we can't exclude all apps, introduce a function to allow skipping single targets when building EP examples. This will allow excluding designer specifically. The examples will now depend on a new ${repo}_src_for_examples target rather than ${repo}_src, which will exclude skipped targets. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Task-number: QTBUG-110369 Change-Id: I2f900253bbf7bac917f2293ef604ab3ea8f298e1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-01-19 17:55:58 +00:00
# Marks a target with a property to skip it adding it as a dependency when building examples as
# ExternalProjects.
# Needed to create a ${repo}_src global target that examples can depend on in multi-config builds
# due to a bug in AUTOUIC.
#
# See QTBUG-110369.
function(qt_internal_skip_dependency_for_examples target)
set_target_properties(${target} PROPERTIES _qt_skip_dependency_for_examples TRUE)
endfunction()
function(qt_internal_is_target_skipped_for_examples target out_var)
get_property(is_skipped TARGET ${target} PROPERTY _qt_skip_dependency_for_examples)
if(NOT is_skipped)
set(is_skipped FALSE)
endif()
set(${out_var} "${is_skipped}" PARENT_SCOPE)
endfunction()
CMake: Apply bitcode flags to internal plugin object lib initializers All internal libraries, plugins, object libraries (resources, plugin initializers) need to be built with bitcode flags when targeting iOS. Internal here means all libraries added by qt_internal_add_X functions or associated with internal libraries. We didn't do that for plugin initializers, which were added not too long ago. Extract the logic that links to Qt::PlatformModuleInternal into a separate function to be used for object libraries. Use it for resources and plugin initializers. It will also be used in qtdeclarative for qml plugin initializers. Pick-to: 6.2 Task-number: QTBUG-95208 Change-Id: I366996078f5e9d1c2d2797f6b81c522ee99529e3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-15 11:41:15 +00:00
function(qt_internal_link_internal_platform_for_object_library target)
Consider the main target flags related properties when building object libraries The object libraries that are side products from building plugins should also consider the properties that control the flag handling of their main plugin targets, otherwise they will inherit the PlatformInternal flags without knowing what their parent decide. Functionality now considers QT_SKIP_WARNINGS_ARE_ERRORS and _qt_internal_use_exceptions properties. The list can be extended in the future. Change-Id: If304b3b382d6cd05064bc87e11d3cc87ba7c0d7b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-09-10 16:20:51 +00:00
cmake_parse_arguments(arg "" "PARENT_TARGET" "" ${ARGN})
CMake: Apply bitcode flags to internal plugin object lib initializers All internal libraries, plugins, object libraries (resources, plugin initializers) need to be built with bitcode flags when targeting iOS. Internal here means all libraries added by qt_internal_add_X functions or associated with internal libraries. We didn't do that for plugin initializers, which were added not too long ago. Extract the logic that links to Qt::PlatformModuleInternal into a separate function to be used for object libraries. Use it for resources and plugin initializers. It will also be used in qtdeclarative for qml plugin initializers. Pick-to: 6.2 Task-number: QTBUG-95208 Change-Id: I366996078f5e9d1c2d2797f6b81c522ee99529e3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-15 11:41:15 +00:00
# We need to apply iOS bitcode flags to object libraries that are associated with internal
# modules or plugins (e.g. object libraries added by qt_internal_add_resource,
# qt_internal_add_plugin, etc.)
# The flags are needed when building iOS apps because Xcode expects bitcode to be
# present by default.
# Achieve this by compiling the cpp files with the PlatformModuleInternal compile flags.
target_link_libraries("${target}" PRIVATE Qt::PlatformModuleInternal)
Consider the main target flags related properties when building object libraries The object libraries that are side products from building plugins should also consider the properties that control the flag handling of their main plugin targets, otherwise they will inherit the PlatformInternal flags without knowing what their parent decide. Functionality now considers QT_SKIP_WARNINGS_ARE_ERRORS and _qt_internal_use_exceptions properties. The list can be extended in the future. Change-Id: If304b3b382d6cd05064bc87e11d3cc87ba7c0d7b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-09-10 16:20:51 +00:00
if(arg_PARENT_TARGET AND TARGET "${arg_PARENT_TARGET}")
foreach(property QT_SKIP_WARNINGS_ARE_ERRORS _qt_internal_use_exceptions)
set_property(TARGET "${target}" PROPERTY
${property} "$<BOOL:$<TARGET_PROPERTY:${arg_PARENT_TARGET},${property}>>")
endforeach()
endif()
CMake: Apply bitcode flags to internal plugin object lib initializers All internal libraries, plugins, object libraries (resources, plugin initializers) need to be built with bitcode flags when targeting iOS. Internal here means all libraries added by qt_internal_add_X functions or associated with internal libraries. We didn't do that for plugin initializers, which were added not too long ago. Extract the logic that links to Qt::PlatformModuleInternal into a separate function to be used for object libraries. Use it for resources and plugin initializers. It will also be used in qtdeclarative for qml plugin initializers. Pick-to: 6.2 Task-number: QTBUG-95208 Change-Id: I366996078f5e9d1c2d2797f6b81c522ee99529e3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-15 11:41:15 +00:00
endfunction()
CMake: Make WrapVulkanHeaders target optional for QtGui consumers If Vulkan headers are present on the system when qtbase is configured, QtGui and QtOpenGL should be compiled with Vulkan support. If a user project uses a Qt built with Vulkan support, but their system is missing Vulkan headers, the project configuration needs to succeed. The project will get compilation errors if it uses Vulkan headers, but that's intended. This use case was broken when fixing Vulkan to be found when building Qt for Android. Fix the regression with a combination of things 1) Mark the WrapVulkanHeaders package as optional (already the case) 2) Use the include directories directly when compiling Gui and OpenGL 3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to consumers only if the target exists. It won't exist if Vulkan include dirs are not found This also requires some changes in pri and prl file generation. For prl file generation, we don't want to link to the WrapVulkanHeaders target, so we filter out all dependencies that use TARGET_NAME_IF_EXISTS for anything that calls __qt_internal_walk_libs which includes qt_collect_libs. For pri files, we make sure to generate a uses=vulkan/nolink clause by inspecting a new _qt_is_nolink_target property on the target. We also don't add include dirs to the pri file if the new _qt_skip_include_dir_for_pri property is set. This is intended for Vulkan, because there is separate qmake logic to try and find the include dirs when configuring a user project. As a drive-by, fix nolink handling for WrapOpenSSLHeaders. Amends bb25536a3db657b41ae31e1690d230ef8722b57d Amends 7b9904849fe1a43f0db8216076a9e974ebca5c78 Pick-to: 6.2 Fixes: QTBUG-95391 Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-27 11:54:56 +00:00
Don't export Qt6::ATSPI2_nolink target in Qt6GuiTargets.cmake We don't have any APSPI2 includes in our public headers and should therefore not export the target that provides ATSPI2 include paths for consumers. Link against PkgConfig::ATSPI2 instead of the _nolink target. The former will not be exported. Pick-to: 6.2 Fixes: QTBUG-97023 Change-Id: I4b12e0c2230917feeb963c02565e6db24f757bd3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-10-01 07:48:42 +00:00
# Use ${dep_target}'s include dirs when building ${target}.
#
# Assumes ${dep_target} is an INTERFACE_LIBRARY that only propagates include dirs and ${target}
# is a Qt module / plugin.
#
# Building ${target} requires ${dep_target}'s include dirs.
# Using ${target} does not require ${dep_target}'s include dirs.
#
# The main use case is adding the private header-only dependency PkgConfig::ATSPI2.
function(qt_internal_add_target_include_dirs target dep_target)
if(NOT TARGET "${target}")
message(FATAL_ERROR "${target} is not a valid target.")
endif()
if(NOT TARGET "${dep_target}")
message(FATAL_ERROR "${dep_target} is not a valid target.")
endif()
target_include_directories("${target}" PRIVATE
"$<TARGET_PROPERTY:${dep_target},INTERFACE_INCLUDE_DIRECTORIES>")
endfunction()
CMake: Make WrapVulkanHeaders target optional for QtGui consumers If Vulkan headers are present on the system when qtbase is configured, QtGui and QtOpenGL should be compiled with Vulkan support. If a user project uses a Qt built with Vulkan support, but their system is missing Vulkan headers, the project configuration needs to succeed. The project will get compilation errors if it uses Vulkan headers, but that's intended. This use case was broken when fixing Vulkan to be found when building Qt for Android. Fix the regression with a combination of things 1) Mark the WrapVulkanHeaders package as optional (already the case) 2) Use the include directories directly when compiling Gui and OpenGL 3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to consumers only if the target exists. It won't exist if Vulkan include dirs are not found This also requires some changes in pri and prl file generation. For prl file generation, we don't want to link to the WrapVulkanHeaders target, so we filter out all dependencies that use TARGET_NAME_IF_EXISTS for anything that calls __qt_internal_walk_libs which includes qt_collect_libs. For pri files, we make sure to generate a uses=vulkan/nolink clause by inspecting a new _qt_is_nolink_target property on the target. We also don't add include dirs to the pri file if the new _qt_skip_include_dir_for_pri property is set. This is intended for Vulkan, because there is separate qmake logic to try and find the include dirs when configuring a user project. As a drive-by, fix nolink handling for WrapOpenSSLHeaders. Amends bb25536a3db657b41ae31e1690d230ef8722b57d Amends 7b9904849fe1a43f0db8216076a9e974ebca5c78 Pick-to: 6.2 Fixes: QTBUG-95391 Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-27 11:54:56 +00:00
# Use ${dep_target}'s include dirs when building ${target} and optionally propagate the include
# dirs to consumers of ${target}.
# Assumes ${dep_target} is an INTERFACE_LIBRARY that only propagates include dirs and ${target}
# is a Qt module / plugin.
#
# Building ${target} requires ${dep_target}'s include dirs.
#
# User projects that don't have ${dep_target}'s headers installed in their system should still
# configure successfully.
#
# To achieve that, consumers of ${target} will only get the include directories of ${dep_target}
# if the latter package and target exists.
#
CMake: Clarify qt_record_extra_third_party_dependency docs Pick-to: 6.4 Change-Id: I458a5b488741c639650c8b3b6668c82c80b5e93f Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-08 15:11:59 +00:00
# A find_package(dep_target) dependency is added to ${target}'s *Dependencies.cmake file.
CMake: Make WrapVulkanHeaders target optional for QtGui consumers If Vulkan headers are present on the system when qtbase is configured, QtGui and QtOpenGL should be compiled with Vulkan support. If a user project uses a Qt built with Vulkan support, but their system is missing Vulkan headers, the project configuration needs to succeed. The project will get compilation errors if it uses Vulkan headers, but that's intended. This use case was broken when fixing Vulkan to be found when building Qt for Android. Fix the regression with a combination of things 1) Mark the WrapVulkanHeaders package as optional (already the case) 2) Use the include directories directly when compiling Gui and OpenGL 3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to consumers only if the target exists. It won't exist if Vulkan include dirs are not found This also requires some changes in pri and prl file generation. For prl file generation, we don't want to link to the WrapVulkanHeaders target, so we filter out all dependencies that use TARGET_NAME_IF_EXISTS for anything that calls __qt_internal_walk_libs which includes qt_collect_libs. For pri files, we make sure to generate a uses=vulkan/nolink clause by inspecting a new _qt_is_nolink_target property on the target. We also don't add include dirs to the pri file if the new _qt_skip_include_dir_for_pri property is set. This is intended for Vulkan, because there is separate qmake logic to try and find the include dirs when configuring a user project. As a drive-by, fix nolink handling for WrapOpenSSLHeaders. Amends bb25536a3db657b41ae31e1690d230ef8722b57d Amends 7b9904849fe1a43f0db8216076a9e974ebca5c78 Pick-to: 6.2 Fixes: QTBUG-95391 Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-27 11:54:56 +00:00
#
# We use target_include_directories(PRIVATE) instead of target_link_libraries(PRIVATE) because the
# latter would propagate a mandatory LINK_ONLY dependency on the ${dep_target} in a static Qt build.
#
# The main use case is for propagating WrapVulkanHeaders::WrapVulkanHeaders.
function(qt_internal_add_target_include_dirs_and_optionally_propagate target dep_target)
Don't export Qt6::ATSPI2_nolink target in Qt6GuiTargets.cmake We don't have any APSPI2 includes in our public headers and should therefore not export the target that provides ATSPI2 include paths for consumers. Link against PkgConfig::ATSPI2 instead of the _nolink target. The former will not be exported. Pick-to: 6.2 Fixes: QTBUG-97023 Change-Id: I4b12e0c2230917feeb963c02565e6db24f757bd3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-10-01 07:48:42 +00:00
qt_internal_add_target_include_dirs(${target} ${dep_target})
CMake: Make WrapVulkanHeaders target optional for QtGui consumers If Vulkan headers are present on the system when qtbase is configured, QtGui and QtOpenGL should be compiled with Vulkan support. If a user project uses a Qt built with Vulkan support, but their system is missing Vulkan headers, the project configuration needs to succeed. The project will get compilation errors if it uses Vulkan headers, but that's intended. This use case was broken when fixing Vulkan to be found when building Qt for Android. Fix the regression with a combination of things 1) Mark the WrapVulkanHeaders package as optional (already the case) 2) Use the include directories directly when compiling Gui and OpenGL 3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to consumers only if the target exists. It won't exist if Vulkan include dirs are not found This also requires some changes in pri and prl file generation. For prl file generation, we don't want to link to the WrapVulkanHeaders target, so we filter out all dependencies that use TARGET_NAME_IF_EXISTS for anything that calls __qt_internal_walk_libs which includes qt_collect_libs. For pri files, we make sure to generate a uses=vulkan/nolink clause by inspecting a new _qt_is_nolink_target property on the target. We also don't add include dirs to the pri file if the new _qt_skip_include_dir_for_pri property is set. This is intended for Vulkan, because there is separate qmake logic to try and find the include dirs when configuring a user project. As a drive-by, fix nolink handling for WrapOpenSSLHeaders. Amends bb25536a3db657b41ae31e1690d230ef8722b57d Amends 7b9904849fe1a43f0db8216076a9e974ebca5c78 Pick-to: 6.2 Fixes: QTBUG-95391 Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-27 11:54:56 +00:00
target_link_libraries("${target}" INTERFACE "$<TARGET_NAME_IF_EXISTS:${dep_target}>")
qt_record_extra_third_party_dependency("${target}" "${dep_target}")
endfunction()
Add qt_internal_undefine_global_definition function qt_internal_undefine_global_definition disables an internal global definition that is defined by the qt_internal_add_global_definition function for a specific target. Remove the ability to set the custom "undefine" flag for the definitions since it's hard to control it using the introduced function. Pick-to: 6.2 6.3 Task-number: QTBUG-100334 Change-Id: Ic1637d97aa51bbdd06c5b191c57a941aa208d4dc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-01-31 17:53:57 +00:00
# The function disables one or multiple internal global definitions that are defined by the
# qt_internal_add_global_definition function for a specific 'target'.
function(qt_internal_undefine_global_definition target)
Make qt cmake functions react properly to batch dummy targets Stub targets introduced in 65b7aacb make the old batch target detecting measure in qt_internal_extend_target, qt_internal_undefine_global_definition, qt_internal_add_resource obsolete, since now the targets actually exist in the build system. Unconditionally fail if the target does not exist and if it does, query for its inclusion in the batch Change-Id: I1cd1d8cc7fbf4bdbd2289a1b38ecbea1e93a06c8 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2023-01-02 18:19:44 +00:00
if(NOT TARGET "${target}")
message(FATAL_ERROR "${target} is not a target.")
endif()
Skip tests outside of qtbase on batching+superbuild The batcher does not currently work properly with non-qtbase submodules. Disable them temporarily so that at least the tests in qtbase are batched. Do this from qtbase so that changes to each and every submodule are not necessary. Also, maintain a list of tests that were thus skipped. On any qt cmake internal function call that refers to such a target, identify the target as skipped and make the call a no-op. Fixes: QTBUG-109785 Change-Id: Ib0aa5d39eee8315ffd4ac62f6d1f44fe9bbf7a2f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-03 13:42:33 +00:00
qt_internal_is_skipped_test(skipped ${target})
if(skipped)
return()
endif()
Make qt cmake functions react properly to batch dummy targets Stub targets introduced in 65b7aacb make the old batch target detecting measure in qt_internal_extend_target, qt_internal_undefine_global_definition, qt_internal_add_resource obsolete, since now the targets actually exist in the build system. Unconditionally fail if the target does not exist and if it does, query for its inclusion in the batch Change-Id: I1cd1d8cc7fbf4bdbd2289a1b38ecbea1e93a06c8 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2023-01-02 18:19:44 +00:00
qt_internal_is_in_test_batch(in_batch ${target})
if(in_batch)
Make qt_internal_test_batch_target_name publicly available The batch test target name is a useful thing to obtain in various target-generating scripts. Change-Id: I9605cf860fe1485e48108eba7e93f9064209d8fb Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-24 07:28:37 +00:00
_qt_internal_test_batch_target_name(target)
Add qt_internal_undefine_global_definition function qt_internal_undefine_global_definition disables an internal global definition that is defined by the qt_internal_add_global_definition function for a specific target. Remove the ability to set the custom "undefine" flag for the definitions since it's hard to control it using the introduced function. Pick-to: 6.2 6.3 Task-number: QTBUG-100334 Change-Id: Ic1637d97aa51bbdd06c5b191c57a941aa208d4dc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-01-31 17:53:57 +00:00
endif()
if("${ARGN}" STREQUAL "")
message(FATAL_ERROR "The function expects at least one definition as an argument.")
endif()
foreach(definition IN LISTS ARGN)
set(undef_property_name "QT_INTERNAL_UNDEF_${definition}")
set_target_properties(${target} PROPERTIES "${undef_property_name}" TRUE)
endforeach()
endfunction()
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
# This function adds any defines which are local to the current repository (e.g. qtbase,
# qtmultimedia). Those can be defined in the corresponding .cmake.conf file via
# QT_EXTRA_INTERNAL_TARGET_DEFINES. QT_EXTRA_INTERNAL_TARGET_DEFINES accepts a list of definitions.
# The definitions are passed to target_compile_definitions, which means that values can be provided
# via the FOO=Bar syntax
# This does nothing for interface targets
function(qt_internal_add_repo_local_defines target)
get_target_property(type "${target}" TYPE)
if (${type} STREQUAL "INTERFACE_LIBRARY")
return()
endif()
if(DEFINED QT_EXTRA_INTERNAL_TARGET_DEFINES)
target_compile_definitions("${target}" PRIVATE ${QT_EXTRA_INTERNAL_TARGET_DEFINES})
endif()
endfunction()
Add possibility to store source files for interface targets Add source files to the _qt_internal_target_sources property, when running qt_internal_extend_target on interface libraries instead of ignoring sources for CMake versions that don't support non-interface properties. The property is not full-functional, but still allows to execute internal routines on target sources. Also add qt_internal_get_target_sources_property function that helps to destinguish which property stores target sources. Task-number: QTBUG-103196 Change-Id: I435c558090a24a7988f1a1c49f924dc195e72480 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-10 15:21:18 +00:00
# The function returns the value of the target's SOURCES property. The function takes into account
# the limitation of the CMake version less than 3.19, that restricts to add non-interface sources
# to an interface target.
# Note: The function works correctly only if qt_internal_extend_target is used when adding source
# files.
function(qt_internal_get_target_sources out_var target)
qt_internal_get_target_sources_property(sources_property)
get_target_property(${out_var} ${target} ${sources_property})
set(${out_var} "${${out_var}}" PARENT_SCOPE)
endfunction()
# The function distinguishes what property supposed to store target sources, based on target TYPE
# and the CMake version.
function(qt_internal_get_target_sources_property out_var)
set(${out_var} "SOURCES")
get_target_property(target_type ${target} TYPE)
if(CMAKE_VERSION VERSION_LESS "3.19" AND target_type STREQUAL "INTERFACE_LIBRARY")
set(${out_var} "_qt_internal_target_sources")
endif()
set(${out_var} "${${out_var}}" PARENT_SCOPE)
endfunction()
Add support for evaluating genexes when exporting custom target props Properties specified in EXPORT_PROPERTIES have their values exported verbatim, without evaluating generator expression they might contain. This limitation is removed by the introduced functions. They collect properties that needs to be exported and evaluate generator expressions inside the properties using file(GENERATE) before exporting them. The functions generate the ExtraProperties.cmake file that contains set_property calls with exported properties and corresponding values. Change-Id: If32c30a82a62e8bd48bb91f3df21ff2ad8d07243 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-05-13 16:24:22 +00:00
# This function collects target properties that contain generator expressions and needs to be
# exported. This function is needed since the CMake EXPORT_PROPERTIES property doesn't support
# properties that contain generator expressions.
# Usage: qt_internal_add_genex_properties_export(target properties...)
function(qt_internal_add_genex_properties_export target)
get_cmake_property(is_multi_config GENERATOR_IS_MULTI_CONFIG)
set(config_check_begin "")
set(config_check_end "")
if(is_multi_config)
list(GET CMAKE_CONFIGURATION_TYPES 0 first_config_type)
# The genex snippet is evaluated to '$<NOT:$<BOOL:$<CONFIG>>>' in the generated cmake file.
# The check is only applicable to the 'main' configuration. If user project doesn't use
# multi-config generator, then the check supposed to return true and the value from the
# 'main' configuration supposed to be used.
string(JOIN "" check_if_config_empty
"$<1:$><NOT:"
"$<1:$><BOOL:"
"$<1:$><CONFIG$<ANGLE-R>"
"$<ANGLE-R>"
"$<ANGLE-R>"
)
# The genex snippet is evaluated to '$<CONFIG:'Qt config type'>' in the generated cmake
# file and checks if the config that user uses matches the generated cmake file config.
string(JOIN "" check_user_config
"$<1:$><CONFIG:$<CONFIG>$<ANGLE-R>"
)
# The genex snippet is evaluated to '$<$<OR:$<CONFIG:'Qt config type'>>:'Property content'>
# for non-main Qt configs and to
# $<$<OR:$<CONFIG:'Qt config type'>,$<NOT:$<BOOL:$<CONFIG>>>>:'Property content'> for the
# main Qt config. This guard is required to choose the correct value of the property for the
# user project according to the user config type.
# All genexes need to be escaped properly to protect them from evaluation by the
# file(GENERATE call in the qt_internal_export_genex_properties function.
string(JOIN "" config_check_begin
"$<1:$><"
"$<1:$><OR:"
"${check_user_config}"
"$<$<CONFIG:${first_config_type}>:$<COMMA>${check_if_config_empty}>"
"$<ANGLE-R>:"
)
set(config_check_end "$<ANGLE-R>")
endif()
set(target_name "${QT_CMAKE_EXPORT_NAMESPACE}::${target}")
foreach(property IN LISTS ARGN)
set(target_property_genex "$<TARGET_PROPERTY:${target_name},${property}>")
# All properties that contain lists need to be protected of processing by JOIN genex calls.
# So this escapes the semicolons for these list.
set(target_property_list_escape
"$<JOIN:$<GENEX_EVAL:${target_property_genex}>,\;>")
set(property_value
"\"${config_check_begin}${target_property_list_escape}${config_check_end}\"")
set_property(TARGET ${target} APPEND PROPERTY _qt_export_genex_properties_content
"${property} ${property_value}")
endforeach()
endfunction()
# This function executes generator expressions for the properties that are added by the
# qt_internal_add_genex_properties_export function and sets the calculated values to the
# corresponding properties in the generated ExtraProperties.cmake file. The file then needs to be
# included after the target creation routines in Config.cmake files. It also supports Multi-Config
# builds.
# Arguments:
# EXPORT_NAME_PREFIX:
# The portion of the file name before ExtraProperties.cmake
# CONFIG_INSTALL_DIR:
# Installation location for the file.
# TARGETS:
# The internal target names.
function(qt_internal_export_genex_properties)
set(option_args "")
set(single_args
EXPORT_NAME_PREFIX
CONFIG_INSTALL_DIR
)
set(multi_args TARGETS)
cmake_parse_arguments(arg "${option_args}" "${single_args}" "${multi_args}" ${ARGN})
if(NOT arg_EXPORT_NAME_PREFIX)
message(FATAL_ERROR "qt_internal_export_genex_properties: "
"Missing EXPORT_NAME_PREFIX argument.")
endif()
if(NOT arg_TARGETS)
message(FATAL_ERROR "qt_internal_export_genex_properties: "
"TARGETS argument must contain at least one target")
endif()
foreach(target IN LISTS arg_TARGETS)
get_cmake_property(is_multi_config GENERATOR_IS_MULTI_CONFIG)
set(output_file_base_name "${arg_EXPORT_NAME_PREFIX}ExtraProperties")
set(should_append "")
set(config_suffix "")
if(is_multi_config)
list(GET CMAKE_CONFIGURATION_TYPES 0 first_config_type)
set(config_suffix "$<$<NOT:$<CONFIG:${first_config_type}>>:-$<CONFIG>>")
# If the generated file belongs to the 'main' config type, we should set property
# but not append it.
string(JOIN "" should_append
"$<$<NOT:$<CONFIG:${first_config_type}>>: APPEND>")
endif()
set(file_name "${output_file_base_name}${config_suffix}.cmake")
qt_path_join(output_file "${arg_CONFIG_INSTALL_DIR}"
"${file_name}")
if(NOT IS_ABSOLUTE "${output_file}")
qt_path_join(output_file "${QT_BUILD_DIR}" "${output_file}")
endif()
set(target_name "${QT_CMAKE_EXPORT_NAMESPACE}::${target}")
string(JOIN "" set_property_begin "set_property(TARGET "
"${target_name}${should_append} PROPERTY "
)
set(set_property_end ")")
set(set_property_glue "${set_property_end}\n${set_property_begin}")
set(property_list
"$<GENEX_EVAL:$<TARGET_PROPERTY:${target},_qt_export_genex_properties_content>>")
string(JOIN "" set_property_content "${set_property_begin}"
"$<JOIN:${property_list},${set_property_glue}>"
"${set_property_end}")
if(is_multi_config)
set(config_includes "")
foreach(config IN LISTS CMAKE_CONFIGURATION_TYPES)
if(NOT first_config_type STREQUAL config)
set(include_file_name
"${output_file_base_name}-${config}.cmake")
list(APPEND config_includes
"include(\"\${CMAKE_CURRENT_LIST_DIR}/${include_file_name}\")")
endif()
endforeach()
list(JOIN config_includes "\n" config_includes_string)
set(config_includes_string
"\n$<$<CONFIG:${first_config_type}>:${config_includes_string}>")
endif()
file(GENERATE OUTPUT "${output_file}"
CONTENT "$<$<BOOL:${property_list}>:${set_property_content}${config_includes_string}>"
CONDITION "$<BOOL:${property_list}>"
)
endforeach()
qt_install(FILES "$<$<BOOL:${property_list}>:${output_file}>"
DESTINATION "${arg_CONFIG_INSTALL_DIR}"
COMPONENT Devel
)
endfunction()
Add the the implicit promotion to global for Qt platform targets Bundled 3rdparty libraries link Qt platform targets implicitly, which lead to the dependency resolution when the library is used by another targets. For qtbase this works just fine since all platform targets are not imported and they are used from a build tree. But in case if 3rdparty library is built as part of Qt repo different from qtbase platform targets are imported and trigger the global promotion in CMake. Usually qt_find_package for the 3rdparty libraries is called somewhere in src/... directory and since Qt::Platform* targets are already created in the top-level repo CMakeLists.txt by the find_package(Qt ...) call, this leads to an error. The propsed fix forces the global promotion of Qt platform targets as soon as they created by the one of the initial find_package(Qt ...) calls. Change-Id: Iceb53f9ecccbdc438f9bc3bcc836583cfd4de535 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2024-01-30 15:30:16 +00:00
CMake: Introduce wrappers for the PlatformX and GlobalConfig targets Introduce some command wrappers for adding the Platform, PlatformXInternal and GlobalConfig targets, to apply some common options. This will allow for less churn in the future when we need to apply options to all these targets. The Qt6CoreMacros, Qt6AndroidMacros and Qt6WasmMacros inclusion are moved before QtBaseGlobalTargets to make the _qt_internal_add_library command and other platform specific commands available before we create the Platform targets. Pick-to: 6.8 Change-Id: I260fdbeb95a39f06951dfefc714d3da604abb0bb Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-07-02 13:44:02 +00:00
# A small wrapper for adding the Platform target, and a building block for the PlatformXInternal
# and GlobalConfig INTERFACE targets to apply common options.
function(qt_internal_add_platform_target target)
_qt_internal_add_library("${target}" INTERFACE)
qt_internal_add_target_aliases("${target}")
CMake: Prevent most global promotion errors when building Qt Backstory. The main reason why we keep getting "unable to promote 3rd party 'X' target to global scope" errors when building Qt repositories, is because we try to promote 3rd party imported targets in a different scope than where the imported targets were created. What were the main motivations for promoting 3rd party targets to global? 1) imported targets are by default local to the directory scope they were created in 2) we want 3rd party targets to be accessible across subdirectory scopes, but looked up once, e.g. qt_find_package(JPEG) looked up in src/gui/CMakeLists.txt, but the target should also be usable in the sibling scope src/plugins/imageformats/CMakeLists.txt Having the package lookup close to the consuming qt module is easier to maintain, because all the other 3rd party dependency lookups are in the same file. This goes against the conventional CMake advice where each subdirectory should look for its own dependencies, or the dependency should be available directly in the root project scope. 3) to make the 3rd party targets available in the root project scope as part of the following flow: QtPostProcess.cmake -> qt_internal_create_module_depends_file() -> qt_collect_third_party_deps() -> get_property(INTERFACE_QT_PACKAGE_NAME) -> write 3rd party Dependencies.cmake file for each qt module. Properties can only be queried from an imported target if it's in the same scope or was promoted to global, otherwise you get 'non-existent target' errors. 4) for prl and pri file generation, where we need the targets to be available during generator expression evaluation within the relevant qt module directory scope Here is a list of approaches I came up with on how to improve the situation. 1) Make all imported targets global during the Qt build, by iterating over the directory property IMPORTED_TARGETS and making each one global. Requires CMake 3.21. Status: Already implemented for a long time, but is opt-in. Pros: Relatively robust Cons: Minimum CMake version for building Qt is 3.16. 2) Make all imported targets global during the Qt build using the CMAKE_FIND_PACKAGE_TARGETS_GLOBAL variable. Requires CMake 3.24. Status: Not implemented, but can be set by Qt builders directly on the command line. Pros: Should be robust Cons: Minimum CMake version for building Qt is 3.16. 3) Abandon the desire to have a single qt_find_package in a single directory scope, and embrace the CMake-way of repeating the dependency in each subdirectory that requires it. Status: Not implemented. Pros: Should be robust Cons: A lot of qt_find_package duplication, will require rewriting various code paths, QtPostProcess would have to be done at directory scope, unclear if dependency tracking will still work work reliably when there might be multiple same-named directory-scoped targets, other unknown unknowns 4) Move all qt_find_package calls into a $repo_name/dependencies.cmake file which would be read at project root scope. This would potentially avoid all scoping issues, because all dependencies will have to be specified at root scope. Status: Not implemented. Pros: No duplication Cons: Dependencies are not scoped anymore to module directories, won't be able to conditionally look for dependencies based on module feature evaluation, not clear yet how this will tie into standalone tests which are in tests/ subdir, other unknown unknowns 5) Try to promote as many 3rd party libraries at project root scope as possible. Currently we have 2 general locations where we look up dependencies. One is each qt_find_package call. The other is Qt6FooDependencies.cmake -> _qt_internal_find_third_party_dependencies(). Many 3rd party targets are created by _qt_internal_find_third_party_dependencies() in the root scope, but not promoted, and then we try to promote them in child scopes using qt_find_package, which causes the promotion errors. Starting with 58eefbd0b6169d0749b312268c1ae1e594e04362 and 37a5e001277db9e1392a242171ab2b88cb6c3049 we now record the provided targets of previous qt_find_package calls. So instead of waiting to try and promote targets later during the configuration process, we can make sure we promote the targets at _qt_internal_find_third_party_dependencies() call time, right when we lookup the Qt dependencies of the qt repo, in the root scope. Status: Implemented in this change Notably, we only promote 3rd party targets to global for qt builds, and not user projects, to not accidentally break user project behaviors. Also, we only promote 3rd party targets, and not Qt internal targets like Qt6::Core, Qt6::Platform, Qt6::PlatformCommonInternal, Qt6::GlobalConfig, etc, for a few reasons: - the code that requires targets to be global only cares about 3rd party targets - promoting the internal targets is more prone to breaking, because there is more than one place where find_package(Qt6Foo) might be called, and if that ends up being in a different directory scope, we encounter the same global promotion errors. Some notable cases where this happens: - tests/CMakeLists.txt brings in extra Qt packages via StandaloneTestsConfig.cmake files - qtbase standalone tests qt_internal_qtbase_pre_project_setup() calls find_package(Qt6 COMPONENTS BuildInternals) which ends up creating the Platform target in the root scope instead of the tests/ scope - Qt6::BundledLibpng links against Core, which ends up trying to promote Core's internal dependencies Platform and GlobalConfig To only promote 3rd party targets, we walk the dependencies of an initial target recursively, and skip promoting targets that have the _qt_is_internal_target or _qt_should_skip_global_promotion_always properties set. Pros: Improves the situation compared to the status quo Cons: Still not ideal due to the various filtering of internal targets and having to mark them as such. 6) Avoid promoting targets to global if we can detect that the target was created in a different scope than where we are trying to promote it. We can do that by comparing the target's BINARY_DIR to the CMAKE_CURRENT_BINARY_DIR and skip promotion if they are not equal. Status: Not implemented, but we can consider it because it's quick to do. Pros: More robust than newly implemented approach (5) Cons: Requires CMake 3.18, because trying to read the BINARY_DIR property on an INTERFACE_LIBRARY would error out. Also, if we implement it and make it the default when using 3.18+, we might 'collect' a lot more hidden promotion errors that will only be revealed later once someone uses CMake 3.16 or 3.17, because most will probably use newer CMake versions. Perhaps the trade-off is worth it? Pick-to: 6.8 Fixes: QTBUG-89204 Fixes: QTBUG-94356 Fixes: QTBUG-95052 Fixes: QTBUG-98807 Fixes: QTBUG-125371 Change-Id: I088a17a98ef35aa69537a3ad208c61de40def581 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-07-01 17:10:26 +00:00
# The platform targets should never be promoted to global via the
# _qt_internal_promote_3rd_party_target_to_global command.
set_property(TARGET "${target}" PROPERTY _qt_should_skip_3rd_party_global_promotion TRUE)
set_property(TARGET "${target}" APPEND PROPERTY EXPORT_PROPERTIES
"_qt_should_skip_3rd_party_global_promotion")
CMake: Introduce wrappers for the PlatformX and GlobalConfig targets Introduce some command wrappers for adding the Platform, PlatformXInternal and GlobalConfig targets, to apply some common options. This will allow for less churn in the future when we need to apply options to all these targets. The Qt6CoreMacros, Qt6AndroidMacros and Qt6WasmMacros inclusion are moved before QtBaseGlobalTargets to make the _qt_internal_add_library command and other platform specific commands available before we create the Platform targets. Pick-to: 6.8 Change-Id: I260fdbeb95a39f06951dfefc714d3da604abb0bb Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-07-02 13:44:02 +00:00
endfunction()
# A small wrapper for adding the PlatformXInternal and GlobalConfig INTERFACE targets to apply
# common options.
# They can't be added via qt_internal_add_module, because it automatically links to the
# PlatformInternal targets creating a cyclic dependency.
function(qt_internal_add_platform_internal_target target)
qt_internal_add_platform_target("${target}")
qt_internal_mark_as_internal_library("${target}")
qt_internal_add_sbom("${target}"
TYPE QT_MODULE
IMMEDIATE_FINALIZATION
)
endfunction()
CMake: support reduced relocations for namespaced Qt The dynlist files passed to the linker have hardcoded function names that do not take namespacing into account. We therefore generate the dynlist files at configure time from the qt namespace. Task-number: QTBUG-138543 Pick-to: 6.10 Change-Id: Ib3521b83942548cb09c11687e1701c2308f9d148 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-08-07 02:12:26 +00:00
# A small wrapper for passing --dynamic-list to the linker. It will ensure that the symbols will
# be mangled when qt is compiled in a namespace
function(qt_internal_apply_dynamic_list_linker_flags target dynlist_template)
if(NOT (QT_FEATURE_reduce_relocations AND UNIX AND GCC))
return()
endif()
string(REPLACE ".in" "" dynlist_file "${dynlist_template}")
set(dynlist_file_abspath "${CMAKE_CURRENT_BINARY_DIR}/${dynlist_file}")
if(QT_NAMESPACE)
set(QT_NAMESPACE_PREFIX "${QT_NAMESPACE}::")
set(QT_NAMESPACE_MANGLE_SUFFIX "_${QT_NAMESPACE}")
else()
set(QT_NAMESPACE_PREFIX "")
set(QT_NAMESPACE_MANGLE_SUFFIX "")
endif()
configure_file(
"${dynlist_template}"
"${dynlist_file_abspath}"
)
qt_internal_extend_target(${target}
SOURCES
"${dynlist_template}"
"${dynlist_file_abspath}"
)
target_link_options(${target} PRIVATE "LINKER:--dynamic-list=${dynlist_file_abspath}")
endfunction()