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

215 lines
9.2 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
# 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)
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
__qt_internal_walk_libs("${target}" "${libs_out_var}"
"${rcc_objects_out_var}" "qt_collect_libs_dict" "collect_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
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()
# 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.
Add ABI suffix to .prl files for Android The libraries already contain the ABI suffix, and the .prl files should too. This is a requirement for ABI-stitching of Qt Android builds. Fixes: QTBUG-90023 Change-Id: Ib2a7b3119ace14c8542242fc45f42648840d053a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-30 15:15:33 +00:00
set(final_prl_file_name "${prefix_for_final_prl_name}$<TARGET_FILE_BASE_NAME:${target}>")
if(ANDROID)
string(APPEND final_prl_file_name "_${CMAKE_ANDROID_ARCH_ABI}")
endif()
string(APPEND final_prl_file_name ".prl")
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_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: Fix static library link order when using qmake qmake adds QMAKE_PRL_LIBS values on the link line after the currently processed library. Because CMake adds resource object files into QMAKE_PRL_LIBS, they end up on the link line after the library. This causes issues on Linux with GNU ld and ld.gold, because the linker discards symbols from the library which are then later referenced by the object files. Work around that by placing the path to the library directly into QMAKE_PRL_LIBS after the resource object files. This ensures the linker doesn't discard the symbols required by the resource object files. This means that each library encountered in qmake's LIBS variable will be temporarily referenced twice in qmake's project state: once from LIBS / QMAKE_PRL_TARGET, and once when the QMAKE_PRL_LIBS values are added. On the link line it will appear only once though, because qmake does library deduplication during prl file processing, which only keeps the last occurrence. Amends 4ab54320817ebbb465af343514d21139a654aed3 Pick-to: 6.2 6.3 Fixes: QTBUG-103002 Change-Id: I97647b64de22b158424850915fee62b5fea5f995 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-05-03 14:04:46 +00:00
QMAKE_PRL_TARGET_PATH_FOR_CMAKE = $<TARGET_LINKER_FILE:${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: Fix prl files not to contain hard-coded library paths Make sure to convert absolute paths generated using the $<TARGET_LINKER_FILE> generator expressions into relative paths. Because prl files are generated for both modules and plugins, we need to pass both a list of qt module locations and qt plugin locations to QtFinishPrl.cmake, and then try to make the absolute path relative to each passed directory. A warning assertion is shown if we no relative path could be made, which will cause an absolute path to be embedded. This should not happen though. Amends f4e998125981038e5e50dab8cc56039faaa0b750 Pick-to: 6.2 6.3 6.4 Fixes: QTBUG-104396 Change-Id: Id68395c0dbb20aad5c510d77835cc931b9396556 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-06-20 17:20:34 +00:00
set(qt_plugin_dirs "${QT_BUILD_DIR}/${INSTALL_PLUGINSDIR}")
if(QT_WILL_INSTALL)
list(APPEND qt_plugin_dirs
"${QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX}/${INSTALL_PLUGINSDIR}")
endif()
CMake: Fix qml plugin prl files not to have hardcoded paths The previous fix 754512a64dffa20165e5b08b77e34b82c072f7f8 did not handle qml plugins, which meant that they would still have hardcoded paths and see warnings like the one below when generating the prl files CMake Warning (dev) at cmake/QtFinishPrlFile.cmake:103 (message): Could not determine relative path for library qml/QtQml/WorkerScript/libworkerscriptplugin_debug.a when generating prl file contents. An absolute path will be embedded, which will cause issues if the Qt installation is relocated. Handle qml plugins as well. Amends 754512a64dffa20165e5b08b77e34b82c072f7f8 Amends f4e998125981038e5e50dab8cc56039faaa0b750 Pick-to: 6.2 6.3 6.4 Fixes: QTBUG-104708 Task-number: QTBUG-104396 Change-Id: Icfb1069d1cb0a39a35004b20e58ee6e386d14f3b Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-01 10:42:31 +00:00
set(qt_qml_dirs "${QT_BUILD_DIR}/${INSTALL_QMLDIR}")
if(QT_WILL_INSTALL)
list(APPEND qt_qml_dirs
"${QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX}/${INSTALL_QMLDIR}")
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}")
CMake: Fix generated prl and pri files for MSVC In MSVC static build, if we build Qt with 3rdparty library (e.g. zstd), cmake will add"zstd" (without "-l" prefix) to Qt6Core.prl. Then we use this Qt to build a qmake project, compilation will fail due to missing zstd.obj. Without "-l" prefix, qmake will treat "zstd" as an object file instead of a library. Library names in qt_module.pri and qt_lib_*_private.pri are also missing "-l" prefix. This is because on most compilers, CMAKE_LINK_LIBRARY_FLAG equals "-l". But on MSVC, it is an empty string. So we should pass "-DLINK_LIBRARY_FLAG=-l" for MSVC. Also add "-L/path/to/library" if the library path is not in default linker search directories. This will write un-relocatable paths to prl files only when using 3rdparty libraries to build Qt statically. Usually it's not a problem. In addition, CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is also empty on MSVC. So The third argument of "$<FILTER>" is empty, it is an invalid generator expression. This means no include dir will be written to qt_module.pri and qt_lib_*_private.pri on MSVC. So only use "$<FILTER>" when CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is not empty. Pick-to: 6.1 Change-Id: Ib66f95dc09cf920363a4b9338fb97747dd2f8ab7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-27 11:41:43 +00:00
if(MSVC)
set(link_library_flag "-l")
Fix generated pri and prl files Quote the paths after "-L". Get MSVC’s implicit link directories from $ENV{LIB}. Fix some issues cause by Inconsistent case. Amends 2c49f85380d7ad79d9473e0f42e7afaa36d31af9 Fixes: QTBUG-95198 Pick-to: 6.2 6.1 Change-Id: Ie82f10b088e2764396377726340509f24a4ae8e7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-16 08:28:32 +00:00
file(TO_CMAKE_PATH "$ENV{LIB};${CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES}" implicit_link_directories)
CMake: Fix generated prl and pri files for MSVC In MSVC static build, if we build Qt with 3rdparty library (e.g. zstd), cmake will add"zstd" (without "-l" prefix) to Qt6Core.prl. Then we use this Qt to build a qmake project, compilation will fail due to missing zstd.obj. Without "-l" prefix, qmake will treat "zstd" as an object file instead of a library. Library names in qt_module.pri and qt_lib_*_private.pri are also missing "-l" prefix. This is because on most compilers, CMAKE_LINK_LIBRARY_FLAG equals "-l". But on MSVC, it is an empty string. So we should pass "-DLINK_LIBRARY_FLAG=-l" for MSVC. Also add "-L/path/to/library" if the library path is not in default linker search directories. This will write un-relocatable paths to prl files only when using 3rdparty libraries to build Qt statically. Usually it's not a problem. In addition, CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is also empty on MSVC. So The third argument of "$<FILTER>" is empty, it is an invalid generator expression. This means no include dir will be written to qt_module.pri and qt_lib_*_private.pri on MSVC. So only use "$<FILTER>" when CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is not empty. Pick-to: 6.1 Change-Id: Ib66f95dc09cf920363a4b9338fb97747dd2f8ab7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-27 11:41:43 +00:00
else()
set(link_library_flag ${CMAKE_LINK_LIBRARY_FLAG})
Fix generated pri and prl files Quote the paths after "-L". Get MSVC’s implicit link directories from $ENV{LIB}. Fix some issues cause by Inconsistent case. Amends 2c49f85380d7ad79d9473e0f42e7afaa36d31af9 Fixes: QTBUG-95198 Pick-to: 6.2 6.1 Change-Id: Ie82f10b088e2764396377726340509f24a4ae8e7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-16 08:28:32 +00:00
set(implicit_link_directories ${CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES})
CMake: Fix generated prl and pri files for MSVC In MSVC static build, if we build Qt with 3rdparty library (e.g. zstd), cmake will add"zstd" (without "-l" prefix) to Qt6Core.prl. Then we use this Qt to build a qmake project, compilation will fail due to missing zstd.obj. Without "-l" prefix, qmake will treat "zstd" as an object file instead of a library. Library names in qt_module.pri and qt_lib_*_private.pri are also missing "-l" prefix. This is because on most compilers, CMAKE_LINK_LIBRARY_FLAG equals "-l". But on MSVC, it is an empty string. So we should pass "-DLINK_LIBRARY_FLAG=-l" for MSVC. Also add "-L/path/to/library" if the library path is not in default linker search directories. This will write un-relocatable paths to prl files only when using 3rdparty libraries to build Qt statically. Usually it's not a problem. In addition, CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is also empty on MSVC. So The third argument of "$<FILTER>" is empty, it is an invalid generator expression. This means no include dir will be written to qt_module.pri and qt_lib_*_private.pri on MSVC. So only use "$<FILTER>" when CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is not empty. Pick-to: 6.1 Change-Id: Ib66f95dc09cf920363a4b9338fb97747dd2f8ab7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-27 11:41:43 +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
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}"
CMake: Fix generated prl and pri files for MSVC In MSVC static build, if we build Qt with 3rdparty library (e.g. zstd), cmake will add"zstd" (without "-l" prefix) to Qt6Core.prl. Then we use this Qt to build a qmake project, compilation will fail due to missing zstd.obj. Without "-l" prefix, qmake will treat "zstd" as an object file instead of a library. Library names in qt_module.pri and qt_lib_*_private.pri are also missing "-l" prefix. This is because on most compilers, CMAKE_LINK_LIBRARY_FLAG equals "-l". But on MSVC, it is an empty string. So we should pass "-DLINK_LIBRARY_FLAG=-l" for MSVC. Also add "-L/path/to/library" if the library path is not in default linker search directories. This will write un-relocatable paths to prl files only when using 3rdparty libraries to build Qt statically. Usually it's not a problem. In addition, CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is also empty on MSVC. So The third argument of "$<FILTER>" is empty, it is an invalid generator expression. This means no include dir will be written to qt_module.pri and qt_lib_*_private.pri on MSVC. So only use "$<FILTER>" when CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is not empty. Pick-to: 6.1 Change-Id: Ib66f95dc09cf920363a4b9338fb97747dd2f8ab7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-27 11:41:43 +00:00
"-DLINK_LIBRARY_FLAG=${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: Fix prl files not to contain hard-coded library paths Make sure to convert absolute paths generated using the $<TARGET_LINKER_FILE> generator expressions into relative paths. Because prl files are generated for both modules and plugins, we need to pass both a list of qt module locations and qt plugin locations to QtFinishPrl.cmake, and then try to make the absolute path relative to each passed directory. A warning assertion is shown if we no relative path could be made, which will cause an absolute path to be embedded. This should not happen though. Amends f4e998125981038e5e50dab8cc56039faaa0b750 Pick-to: 6.2 6.3 6.4 Fixes: QTBUG-104396 Change-Id: Id68395c0dbb20aad5c510d77835cc931b9396556 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-06-20 17:20:34 +00:00
"-DQT_PLUGIN_DIRS=${qt_plugin_dirs}"
CMake: Fix qml plugin prl files not to have hardcoded paths The previous fix 754512a64dffa20165e5b08b77e34b82c072f7f8 did not handle qml plugins, which meant that they would still have hardcoded paths and see warnings like the one below when generating the prl files CMake Warning (dev) at cmake/QtFinishPrlFile.cmake:103 (message): Could not determine relative path for library qml/QtQml/WorkerScript/libworkerscriptplugin_debug.a when generating prl file contents. An absolute path will be embedded, which will cause issues if the Qt installation is relocated. Handle qml plugins as well. Amends 754512a64dffa20165e5b08b77e34b82c072f7f8 Amends f4e998125981038e5e50dab8cc56039faaa0b750 Pick-to: 6.2 6.3 6.4 Fixes: QTBUG-104708 Task-number: QTBUG-104396 Change-Id: Icfb1069d1cb0a39a35004b20e58ee6e386d14f3b Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-01 10:42:31 +00:00
"-DQT_QML_DIRS=${qt_qml_dirs}"
Fix generated pri and prl files Quote the paths after "-L". Get MSVC’s implicit link directories from $ENV{LIB}. Fix some issues cause by Inconsistent case. Amends 2c49f85380d7ad79d9473e0f42e7afaa36d31af9 Fixes: QTBUG-95198 Pick-to: 6.2 6.1 Change-Id: Ie82f10b088e2764396377726340509f24a4ae8e7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-16 08:28:32 +00:00
"-DIMPLICIT_LINK_DIRECTORIES=${implicit_link_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
-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