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

423 lines
19 KiB
CMake
Raw Normal View History

CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
# Add libraries to variable ${out_libs_var} in a way that duplicates
# are added at the end. This ensures the library order needed for the
# linker.
function(qt_merge_libs out_libs_var)
foreach(dep ${ARGN})
list(REMOVE_ITEM ${out_libs_var} ${dep})
list(APPEND ${out_libs_var} ${dep})
endforeach()
set(${out_libs_var} ${${out_libs_var}} PARENT_SCOPE)
endfunction()
# Collects the library dependencies of a target.
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
# As well as rcc object file dependencies.
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 takes into account transitive usage requirements.
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
function(qt_collect_libs target libs_out_var rcc_objects_out_var)
qt_internal_walk_libs("${target}" "${libs_out_var}"
"${rcc_objects_out_var}" "qt_collect_libs_dict" "collect_libs")
set("${libs_out_var}" "${${libs_out_var}}" PARENT_SCOPE)
set(${rcc_objects_out_var} "${${rcc_objects_out_var}}" PARENT_SCOPE)
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: 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
# Extracts value from per-target dict key and assigns it to out_var.
# Assumes dict_name to be an existing INTERFACE target.
function(qt_internal_get_dict_key_values out_var target_infix dict_name dict_key)
get_target_property(values "${dict_name}" "INTERFACE_${target_infix}_${dict_key}")
set(${out_var} "${values}" PARENT_SCOPE)
endfunction()
# Assigns 'values' to per-target dict key, including for aliases of the target.
# Assumes dict_name to be an existing INTERFACE target.
function(qt_internal_memoize_values_in_dict target dict_name dict_key values)
# Memoize the computed values for the target as well as its aliases.
#
# Aka assigns the contents of ${values} to INTERFACE_Core, INTERFACE_Qt::Core,
# INTERFACE_Qt6::Core.
#
# Yes, i know it's crazy that target names are legal property names.
#
# Assigning for library aliases is needed to avoid multiple recomputation of values.
# Scenario in the context of qt_internal_walk_libs:
# 'values' are computed for Core target and memoized to INTERFACE_Core.
# When processing Gui, it depends on Qt::Core, but there are no values for INTERFACE_Qt::Core.
set_target_properties(${dict_name} PROPERTIES INTERFACE_${target}_${dict_key} "${values}")
get_target_property(versionless_alias "${target}" "_qt_versionless_alias")
if(versionless_alias)
qt_internal_get_dict_key_values(
versionless_values "${versionless_alias}" "${dict_name}" "${dict_key}")
if(versionless_values MATCHES "-NOTFOUND$")
set_target_properties(${dict_name}
PROPERTIES INTERFACE_${versionless_alias}_${dict_key} "${values}")
endif()
endif()
get_target_property(versionfull_alias "${target}" "_qt_versionfull_alias")
if(versionfull_alias)
qt_internal_get_dict_key_values(
versionfull_values "${versionfull_alias}" "${dict_name}" "${dict_key}")
if(versionfull_values MATCHES "-NOTFOUND$")
set_target_properties(${dict_name}
PROPERTIES INTERFACE_${versionfull_alias}_${dict_key} "${values}")
endif()
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
# Walks a target's link libraries recursively, and performs some actions (poor man's polypmorphism)
#
# out_var is the name of the variable where the result will be assigned. The result is a list of
# libraries, mostly in generator expression form.
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
# rcc_objects_out_var is the name of the variable where the collected rcc object files will be
# assigned (for the initial target and its dependencies)
# dict_name is used for caching the results, and preventing the same target from being processed
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
# twice
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
# operation is a string to tell the function what additional behaviors to execute.
function(qt_internal_walk_libs
target out_var rcc_objects_out_var dict_name operation)
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(collected ${ARGN})
if(target IN_LIST collected)
return()
endif()
list(APPEND collected ${target})
CMake: Introduce Qt6::Startup target Add an abstraction over Qt::WinMain (aka qtmain.lib) and iOS's runtime linker entry point (_qt_main_wrapper). The Core target will now link against the Startup target on all platforms, instead of just WinMain on Windows. The creation and linkage interface definition of the Startup target is done at find_package(Qt6Core) time via the private call of _qt_internal_setup_startup_target(). This will add automatic linkage of WinMain to executables marked with the WIN32_EXECUTABLE property on Windows. As well as the addition of the '-Wl,-e,_qt_main_wrapper' linker flag when linking iOS executables. Qt users can opt out of this behavior by either setting the QT_NO_LINK_QTMAIN property or variable. This is in line with Qt 5 behavior. Task-number: QTBUG-87060 Change-Id: I7d5e9f1be0e402cf8e67e6f55bfd285f9e6b04f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-05 14:49:53 +00:00
cmake: Remove indirection via Startup target for EntryPoint The EntryPoint interface target now contains all the logic for what flags and optional static libraries to add when the entrypoint is enabled. The target property QT_NO_ENTRYPOINT can be used to disable the entrypoint. Change-Id: I9b14ff729366cd6307789c969ebd4b2ca19de77d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-12 11:58:06 +00:00
if(target STREQUAL "${QT_CMAKE_EXPORT_NAMESPACE}::EntryPoint")
# We can't (and don't need to) process EntryPoint because it brings in $<TARGET_PROPERTY:prop>
# genexes which get replaced with $<TARGET_PROPERTY:EntryPoint,prop> genexes in the code below
CMake: Introduce Qt6::Startup target Add an abstraction over Qt::WinMain (aka qtmain.lib) and iOS's runtime linker entry point (_qt_main_wrapper). The Core target will now link against the Startup target on all platforms, instead of just WinMain on Windows. The creation and linkage interface definition of the Startup target is done at find_package(Qt6Core) time via the private call of _qt_internal_setup_startup_target(). This will add automatic linkage of WinMain to executables marked with the WIN32_EXECUTABLE property on Windows. As well as the addition of the '-Wl,-e,_qt_main_wrapper' linker flag when linking iOS executables. Qt users can opt out of this behavior by either setting the QT_NO_LINK_QTMAIN property or variable. This is in line with Qt 5 behavior. Task-number: QTBUG-87060 Change-Id: I7d5e9f1be0e402cf8e67e6f55bfd285f9e6b04f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-05 14:49:53 +00:00
# and that causes 'INTERFACE_LIBRARY targets may only have whitelisted properties.' errors
# with CMake versions equal to or lower than 3.18. These errors are super unintuitive to
# debug because there's no mention that it's happening during a file(GENERATE) call.
return()
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(NOT TARGET ${dict_name})
add_library(${dict_name} INTERFACE IMPORTED GLOBAL)
endif()
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
qt_internal_get_dict_key_values(libs "${target}" "${dict_name}" "libs")
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
qt_internal_get_dict_key_values(rcc_objects "${target}" "${dict_name}" "rcc_objects")
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
if(libs MATCHES "-NOTFOUND$")
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
unset(libs)
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
unset(rcc_objects)
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_libs ${target} INTERFACE_LINK_LIBRARIES)
if(NOT target_libs)
unset(target_libs)
endif()
get_target_property(target_type ${target} TYPE)
if(target_type STREQUAL "STATIC_LIBRARY")
get_target_property(link_libs ${target} LINK_LIBRARIES)
if(link_libs)
list(APPEND target_libs ${link_libs})
endif()
endif()
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
# Need to record the rcc object file info not only for dependencies, but also for
# the current target too. Otherwise the saved information is incomplete for prl static
# build purposes.
CMake: Rename the qt resource properties to be internal Use lowercase underscored property names. This ensures they will continue to work even for INTERFACE libraries if it ever comes to that. Change-Id: I5281070f25c1eb9f591c79af8b7fa6169c7c0fb7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-17 16:51:42 +00:00
get_target_property(main_target_rcc_objects ${target} _qt_rcc_objects)
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
if(main_target_rcc_objects)
qt_merge_libs(rcc_objects ${main_target_rcc_objects})
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
foreach(lib ${target_libs})
# Cannot use $<TARGET_POLICY:...> in add_custom_command.
# Check the policy now, and replace the generator expression with the value.
while(lib MATCHES "\\$<TARGET_POLICY:([^>]+)>")
cmake_policy(GET ${CMAKE_MATCH_1} value)
if(value STREQUAL "NEW")
set(value "TRUE")
else()
set(value "FALSE")
endif()
string(REPLACE "${CMAKE_MATCH_0}" "${value}" lib "${lib}")
endwhile()
# Fix up $<TARGET_PROPERTY:FOO> expressions that refer to the "current" target.
# Those cannot be used with add_custom_command.
while(lib MATCHES "\\$<TARGET_PROPERTY:([^,>]+)>")
string(REPLACE "${CMAKE_MATCH_0}" "$<TARGET_PROPERTY:${target},${CMAKE_MATCH_1}>"
lib "${lib}")
endwhile()
# Skip static plugins.
set(_is_plugin_marker_genex "\\$<BOOL:QT_IS_PLUGIN_GENEX>")
if(lib MATCHES "${_is_plugin_marker_genex}")
continue()
endif()
# Strip any directory scope tokens.
qt_internal_strip_target_directory_scope_token("${lib}" lib)
if(lib MATCHES "^\\$<TARGET_OBJECTS:")
# Skip object files.
continue()
elseif(lib MATCHES "^\\$<LINK_ONLY:(.*)>$")
set(lib_target ${CMAKE_MATCH_1})
else()
set(lib_target ${lib})
endif()
# Skip CMAKE_DIRECTORY_ID_SEP. If a target_link_libraries is applied to a target
# that was defined in a different scope, CMake appends and prepends a special directory
# id separator. Filter those out.
if(lib_target MATCHES "^::@")
continue()
elseif(TARGET ${lib_target})
if ("${lib_target}" MATCHES "^Qt::(.*)")
# If both, Qt::Foo and Foo targets exist, prefer the target name without
# namespace. Which one is preferred doesn't really matter. This code exists to
# avoid ending up with both, Qt::Foo and Foo in our dependencies.
set(namespaceless_lib_target "${CMAKE_MATCH_1}")
if(TARGET namespaceless_lib_target)
set(lib_target ${namespaceless_lib_target})
endif()
endif()
get_target_property(lib_target_type ${lib_target} TYPE)
if(lib_target_type STREQUAL "INTERFACE_LIBRARY")
qt_internal_walk_libs(
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
${lib_target}
lib_libs_${target}
lib_rcc_objects_${target}
"${dict_name}" "${operation}" ${collected})
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
if(lib_libs_${target})
qt_merge_libs(libs ${lib_libs_${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
set(is_module 0)
endif()
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
if(lib_rcc_objects_${target})
qt_merge_libs(rcc_objects ${lib_rcc_objects_${target}})
endif()
Fix linking order of the resource objects The generated object resource library depends on the Qt::Core library because uses the functions defined in qresource.cpp. Dummy linking of the Qt::Core to an object library has an effect only when the object library is linked directly to the executable as a target. If we link the object library as INTERFACE library we miss out all the objects that need to be linked to the executable. This behavior is explained here: https://bit.ly/3sFWKvI Thus, the only option to link the object library objects to the endpoint executable is to use TARGET_OBJECTS property in genex, as it's already done. But that means we are losing all profits that target actually has, especially linking the object library dependencies. The combination of both of the above methods does the job. The only thing that looks fragile so far is order. Currently, the order we use in the target_link_library call applies to the linker command line. This means the object library objects must always appear before the object library target. Change-Id: If1f0e35e0445d5e96a1f2249ab44114cd36630e9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-29 13:28:16 +00:00
elseif(NOT lib_target_type STREQUAL "OBJECT_LIBRARY")
Fix QMAKE_PRL_LIBS entries on Windows for modules from other repos When building a repository != qtbase, like qtactiveqt, QMAKE_PRL_LIBS contained entries like Qt6Core and Qt6Widgets, meaning the linker line would contain exactly these arguments. When building an activeqt example with qmake, the link then failed with "LNK1181: cannot open input file 'Qt6Widgets.obj'". The correct entry would have been $$[QT_INSTALL_LIBS]/Qt6Widgets.obj. Fix this by determining the full path to the import library in the first step of the prl generation. This enables QtFinishPrlFile.cmake to recognize Qt6Widgets as Qt module and generate the right QMAKE_PRL_LIBS entry. Pick-to: 6.0 Fixes: QTBUG-90520 Change-Id: Id0d9178da0e0dfc3ea4fadbbe8f5900d792ffc84 Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2021-01-21 14:31:09 +00:00
qt_merge_libs(libs "$<TARGET_LINKER_FILE:${lib_target}>")
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
CMake: Rename the qt resource properties to be internal Use lowercase underscored property names. This ensures they will continue to work even for INTERFACE libraries if it ever comes to that. Change-Id: I5281070f25c1eb9f591c79af8b7fa6169c7c0fb7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-17 16:51:42 +00:00
get_target_property(target_rcc_objects "${lib_target}" _qt_rcc_objects)
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
if(target_rcc_objects)
qt_merge_libs(rcc_objects ${target_rcc_objects})
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
qt_internal_walk_libs(
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
${lib_target}
lib_libs_${target}
lib_rcc_objects_${target}
"${dict_name}" "${operation}" ${collected})
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
if(lib_libs_${target})
qt_merge_libs(libs ${lib_libs_${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()
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
if(lib_rcc_objects_${target})
qt_merge_libs(rcc_objects ${lib_rcc_objects_${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
endif()
if(operation STREQUAL "promote_global")
set(lib_target_unaliased "${lib_target}")
get_target_property(aliased_target ${lib_target} ALIASED_TARGET)
if(aliased_target)
set(lib_target_unaliased ${aliased_target})
endif()
get_property(is_imported TARGET ${lib_target_unaliased} PROPERTY IMPORTED)
get_property(is_global TARGET ${lib_target_unaliased} PROPERTY IMPORTED_GLOBAL)
# Allow opting out of promotion. This is useful in certain corner cases
# like with WrapLibClang and Threads in qttools.
qt_internal_should_not_promote_package_target_to_global(
"${lib_target_unaliased}" should_not_promote)
if(NOT is_global AND is_imported AND NOT should_not_promote)
set_property(TARGET ${lib_target_unaliased} PROPERTY IMPORTED_GLOBAL TRUE)
endif()
endif()
Check if all required Qt targets are declared when finalizing the module CMake makes possible to specify a target in the target_link_library call even if the target is not declared yet. This adds flexibility to the target declaration arrangement. For the Qt modules we have to restrict freedom, because of the .prl files generating. If the Qt module depends on another Qt module, the dependecy must be declared before the module finalizing step, otherwise this will cause invalid records in the module .prl file. TODO: The dependency order issue could be solved by using conditional genex's when generating step1 .prl file. But we ask developers to depend on Qt module targets that have been defined before their usage. Fixes: QTBUG-89467 Change-Id: I12ce1000048fd4a2f3334f17720c8df1c680ca20 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-09 10:56:23 +00:00
elseif("${lib_target}" MATCHES "^Qt::(.*)")
message(FATAL_ERROR "The ${CMAKE_MATCH_1} target is mentioned as a dependency for \
${target}, but not declared.")
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()
set(final_lib_name_to_merge "${lib_target}")
if(lib_target MATCHES "/([^/]+).framework$")
set(final_lib_name_to_merge "-framework ${CMAKE_MATCH_1}")
endif()
qt_merge_libs(libs "${final_lib_name_to_merge}")
endif()
endforeach()
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
qt_internal_memoize_values_in_dict("${target}" "${dict_name}" "libs" "${libs}")
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
qt_internal_memoize_values_in_dict("${target}" "${dict_name}"
"rcc_objects" "${rcc_objects}")
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
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(${out_var} ${libs} PARENT_SCOPE)
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
set(${rcc_objects_out_var} ${rcc_objects} PARENT_SCOPE)
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()
# Generate a qmake .prl file for the given target.
# The install_dir argument is a relative path, for example "lib".
function(qt_generate_prl_file target install_dir)
get_target_property(target_type ${target} TYPE)
if(target_type STREQUAL "INTERFACE_LIBRARY")
return()
endif()
unset(prl_config)
set(is_static FALSE)
if(target_type STREQUAL "STATIC_LIBRARY")
list(APPEND prl_config static)
set(is_static TRUE)
elseif(target_type STREQUAL "SHARED_LIBRARY")
list(APPEND prl_config shared)
endif()
if (NOT target_type STREQUAL "INTERFACE_LIBRARY")
get_target_property(is_fw ${target} FRAMEWORK)
if(is_fw)
list(APPEND prl_config lib_bundle)
endif()
endif()
list(JOIN prl_config " " prl_config)
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
set(rcc_objects "")
set(prl_step1_content_libs "")
if(NOT is_static AND WIN32)
# Do nothing. Prl files for shared libraries on Windows shouldn't have the libs listed,
# as per qt_build_config.prf and the conditional CONFIG+=explicitlib assignment.
else()
set(prl_libs "")
qt_collect_libs(${target} prl_libs prl_rcc_objects)
if(prl_libs)
set(prl_step1_content_libs "QMAKE_PRL_LIBS_FOR_CMAKE = ${prl_libs}\n")
endif()
if(prl_rcc_objects)
list(APPEND rcc_objects ${prl_rcc_objects})
endif()
endif()
if(rcc_objects AND QT_WILL_INSTALL)
CMake: Fix resource object file paths in prl files for prefix builds Before this change, the prl files always assumed that resource object files are installed into $qt_prefix/lib when doing a prefix build. That was true for qt_internal_add_resource calls, but not for qt6_add_qml_module and qt6_target_qml_files. Change qt_internal_record_rcc_object_files to take a new required INSTALL_LOCATION argument. The argument takes a path relative to CMAKE_INSTALL_PREFIX. Modify __qt_propagate_generated_resource to save the relative path of the generated resource source file, which will be used in the computation of the final resource object file location. This is needed because the Qml resource functions place the source files in a different directory layout, e.g. .rcc vs .qmlcache Modify qt_generate_prl_file to prepend $$[QT_INSTALL_PREFIX]/ instead of $$[QT_INSTALL_LIBS]/ for the resource install paths. A follow up patch is done in qtdeclarative to pass the new INSTALL_LOCATION argument from the Qml CMake functions. Amends f9dcade5e795a631b9a2d93c855aa8198d58e24e Task-number: QTBUG-87702 Task-number: QTBUG-88425 Change-Id: Id17bb517b4cb5d00911bfd10a728ba4e0d44871b Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 54d0ca93bca78f8fd31b6761f078e7a96283f183) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2020-11-25 16:54:53 +00:00
list(TRANSFORM rcc_objects PREPEND "$$[QT_INSTALL_PREFIX]/")
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +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
# Generate a preliminary .prl file that contains absolute paths to all libraries
if(MINGW)
# For MinGW, qmake doesn't have a lib prefix in prl files.
set(prefix_for_final_prl_name "")
else()
set(prefix_for_final_prl_name "$<TARGET_FILE_PREFIX:${target}>")
endif()
# For frameworks, the prl file should be placed under the Resources subdir.
get_target_property(is_framework ${target} FRAMEWORK)
if(is_framework)
get_target_property(fw_version ${target} FRAMEWORK_VERSION)
string(APPEND prefix_for_final_prl_name "Versions/${fw_version}/Resources/")
endif()
# What follows is a complicated setup for generating configuration-specific
# prl files. It has to be this way, because add_custom_command doesn't support
# generator expressions in OUTPUT or DEPENDS.
# To circumvent that, we create well known file names with file(GENERATE)
# with configuration specific content, which are then fed to add_custom_command
# that uses these genex-less file names. The actual command will extract the info
# from the configuration-specific files, and create a properly named final prl file.
# The file is named according to a pattern, that is then used in the
# add_custom_command.
set(prl_step1_name_prefix "preliminary_prl_for_${target}_step1_")
set(prl_step1_name_suffix ".prl" )
qt_path_join(prl_step1_path
"${CMAKE_CURRENT_BINARY_DIR}"
"${prl_step1_name_prefix}$<CONFIG>${prl_step1_name_suffix}")
# Same, except instead of containing the prl contents, it will contain the final prl file
# name computed via a generator expression.
set(prl_meta_info_name_prefix "preliminary_prl_meta_info_for_${target}_")
set(prl_meta_info_name_suffix ".txt")
qt_path_join(prl_meta_info_path
"${CMAKE_CURRENT_BINARY_DIR}"
"${prl_meta_info_name_prefix}$<CONFIG>${prl_meta_info_name_suffix}")
# The final prl file name that will be embedded in the file above.
set(final_prl_file_name "${prefix_for_final_prl_name}$<TARGET_FILE_BASE_NAME:${target}>.prl")
qt_path_join(final_prl_file_path "${QT_BUILD_DIR}/${install_dir}" "${final_prl_file_name}")
# Generate the prl content and its final file name into configuration specific files
# whose names we know, and can be used in add_custom_command.
set(prl_step1_content
"RCC_OBJECTS = ${rcc_objects}
QMAKE_PRL_BUILD_DIR = ${CMAKE_CURRENT_BINARY_DIR}
CMake: Fix value of QMAKE_PRL_TARGET in generated .prl files On DLL platforms, the value of QMAKE_PRL_TARGET should be the import library (foo.lib), not the actual DLL (foo.dll). The genex TARGET_LINKER_FILE_NAME provides exactly that. Fixes: QTBUG-88864 Pick-to: 6.0 Change-Id: I553930bb840007772fe8f4612f95e0e320f54107 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-25 16:57:29 +00:00
QMAKE_PRL_TARGET = $<TARGET_LINKER_FILE_NAME:${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
QMAKE_PRL_CONFIG = ${prl_config}
QMAKE_PRL_VERSION = ${PROJECT_VERSION}
CMake: Fix resource objects story in static prl files The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 17:42:23 +00:00
${prl_step1_content_libs}
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
")
file(GENERATE
OUTPUT "${prl_step1_path}"
CONTENT "${prl_step1_content}")
file(GENERATE
OUTPUT "${prl_meta_info_path}"
CONTENT
"FINAL_PRL_FILE_PATH = ${final_prl_file_path}")
set(library_prefixes ${CMAKE_SHARED_LIBRARY_PREFIX} ${CMAKE_STATIC_LIBRARY_PREFIX})
set(library_suffixes
${CMAKE_SHARED_LIBRARY_SUFFIX}
${CMAKE_EXTRA_SHARED_LIBRARY_SUFFIXES}
${CMAKE_STATIC_LIBRARY_SUFFIX})
if(QT_GENERATOR_IS_MULTI_CONFIG)
set(configs ${CMAKE_CONFIGURATION_TYPES})
else()
set(configs ${CMAKE_BUILD_TYPE})
endif()
CMake: Fix generation of prl files for non-qtbase modules Previously we determined if a library represented by an absolute path is a Qt module by checking if it's located in the build dir of the current repo. That is not sufficient for non-qtbase prefix builds, where a Qt module might link against both a module in the current build dir and in the prefix dir. Detect such cases, and rewrite the absolute paths to relocatable paths (either framework flags or paths starting with $$[QT_INSTALL_LIBS]. This should fix building examples with qmake that use QtQuick. Fixes: QTBUG-87840 Change-Id: Icaf8f1a7c66292c80662fd0d5771a5a1628a9899 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-28 17:05:24 +00:00
set(qt_lib_dirs "${QT_BUILD_DIR}/${INSTALL_LIBDIR}")
if(QT_WILL_INSTALL)
list(APPEND qt_lib_dirs
"${QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX}/${INSTALL_LIBDIR}")
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
foreach(config ${configs})
# Output file for dependency tracking, and which will contain the final content.
qt_path_join(prl_step2_path
"${CMAKE_CURRENT_BINARY_DIR}" "preliminary_prl_for_${target}_step2_${config}.prl")
# Input dependency names that are constructed for each config manually
# (no genexes allowed).
qt_path_join(prl_step1_path
"${CMAKE_CURRENT_BINARY_DIR}"
"${prl_step1_name_prefix}${config}${prl_step1_name_suffix}")
qt_path_join(prl_meta_info_path
"${CMAKE_CURRENT_BINARY_DIR}"
"${prl_meta_info_name_prefix}${config}${prl_meta_info_name_suffix}")
add_custom_command(
OUTPUT "${prl_step2_path}"
DEPENDS "${prl_step1_path}"
"${prl_meta_info_path}"
"${QT_CMAKE_DIR}/QtFinishPrlFile.cmake"
"${QT_CMAKE_DIR}/QtGenerateLibHelpers.cmake"
COMMAND ${CMAKE_COMMAND}
"-DIN_FILE=${prl_step1_path}"
"-DIN_META_FILE=${prl_meta_info_path}"
"-DOUT_FILE=${prl_step2_path}"
"-DLIBRARY_PREFIXES=${library_prefixes}"
"-DLIBRARY_SUFFIXES=${library_suffixes}"
"-DLINK_LIBRARY_FLAG=${CMAKE_LINK_LIBRARY_FLAG}"
CMake: Fix generation of prl files for non-qtbase modules Previously we determined if a library represented by an absolute path is a Qt module by checking if it's located in the build dir of the current repo. That is not sufficient for non-qtbase prefix builds, where a Qt module might link against both a module in the current build dir and in the prefix dir. Detect such cases, and rewrite the absolute paths to relocatable paths (either framework flags or paths starting with $$[QT_INSTALL_LIBS]. This should fix building examples with qmake that use QtQuick. Fixes: QTBUG-87840 Change-Id: Icaf8f1a7c66292c80662fd0d5771a5a1628a9899 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-28 17:05:24 +00:00
"-DQT_LIB_DIRS=${qt_lib_dirs}"
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
-P "${QT_CMAKE_DIR}/QtFinishPrlFile.cmake"
VERBATIM
COMMENT "Generating prl file for target ${target}"
)
# Tell the target to depend on the preliminary prl file, to ensure the custom command
# is executed. As a side-effect, this will also create the final prl file that
# is named appropriately. It should not be specified as a BYPRODUCT.
# This allows proper per-file dependency tracking, without having to resort on a POST_BUILD
# step, which means that relinking would happen as well as transitive rebuilding of any
# dependees.
# This is inspired by https://gitlab.kitware.com/cmake/cmake/-/issues/20842
target_sources(${target} PRIVATE "${prl_step2_path}")
endforeach()
# Installation of the .prl file happens globally elsewhere,
# because we have no clue here what the actual file name is.
# What we know however, is the directory where the prl file is created.
# Save that for later, to install all prl files from that directory.
get_property(prl_install_dirs GLOBAL PROPERTY QT_PRL_INSTALL_DIRS)
if(NOT install_dir IN_LIST prl_install_dirs)
set_property(GLOBAL APPEND PROPERTY QT_PRL_INSTALL_DIRS "${install_dir}")
endif()
endfunction()
Reference in New Issue Copy Permalink