AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
12629c6b80
qt5base-lts/cmake/QtFinishPrlFile.cmake

146 lines
7.4 KiB
CMake
Raw Normal View History

CMake: Generate qmake .prl files This commit also adds a qt_finalize_module function that is called for every Qt module after all link dependencies have been added. Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-12 15:16:55 +00:00
# Finish a preliminary .prl file.
#
CMake: Do not use $$[QT_INSTALL_LIBS/get] in generated .prl files We do not support building with qmake from the build directory in prefix builds. Therefore we can just use the standard QT_INSTALL_LIBS property instead of the /get variant. Change-Id: I82ccaf1894fb1dccc9ec18b4984b582b555ce0f8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-06-16 08:36:50 +00:00
# - Replaces occurrences of the build libdir with $$[QT_INSTALL_LIBDIR].
CMake: Generate qmake .prl files This commit also adds a qt_finalize_module function that is called for every Qt module after all link dependencies have been added. Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-12 15:16:55 +00:00
# - Strips version number suffixes from absolute paths, because qmake's lflag
# merging does not handle them correctly.
CMake: Fix generated content of prl files (again) Apply the same kind of transformations to the contents of the prl files as we do for pri files. Mainly, transform system library paths that are absolute, into link flags to make them relocatable across systems. Also change the Qt frameworks to be linked via the -framework flags instead of via absolute paths. Implementation notes Move the common required functions for both QtFinishPrlFile and QtGenerateLibPri into a common QtGenerateLibHelpers.cmake file. Make sure it's listed as a dependency for the custom commands. Also make sure to pass the necessary input values like possible library prefixes and suffixes, as well as the link flag. Task-number: QTBUG-85240 Task-number: QTBUG-85801 Change-Id: I36f24207f92a1d2ed3ed2d81bb96e4e62d927b6e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-07-30 17:17:09 +00:00
# - Transforms absolute library paths into link flags
# aka from "/usr/lib/x86_64-linux-gnu/libcups.so" to "-lcups"
# - Replaces Qt absolute framework paths into a combination of -F$$[QT_INSTALL_LIBS] and
# -framework QtFoo
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
# - Prepends '-l' to values that are not absolute paths, and don't start with a dash
# aka, '-lfoo', '-framework', '-pthread'.
CMake: Generate qmake .prl files This commit also adds a qt_finalize_module function that is called for every Qt module after all link dependencies have been added. Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-12 15:16:55 +00:00
#
Update the comment in QtFinishPrlFile.cmake Clarify that OUT_FILE is not the final .prl anymore and where we get the path of the final .prl from. Change-Id: I4563c6ef1026bc0646e3ac9ab2fac49e426ca07f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-30 15:09:18 +00:00
# The path to the final .prl file is stored in the input file as assignment to FINAL_PRL_FILE_PATH.
#
CMake: Generate qmake .prl files This commit also adds a qt_finalize_module function that is called for every Qt module after all link dependencies have been added. Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-12 15:16:55 +00:00
# This file is to be used in CMake script mode with the following variables set:
Update the comment in QtFinishPrlFile.cmake Clarify that OUT_FILE is not the final .prl anymore and where we get the path of the final .prl from. Change-Id: I4563c6ef1026bc0646e3ac9ab2fac49e426ca07f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-30 15:09:18 +00:00
# IN_FILE: path to the step 1 preliminary .prl file
# OUT_FILE: path to the step 2 preliminary .prl file that is going to be created
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
# QT_LIB_DIRS: list of paths where Qt libraries are located.
# This includes the install prefix and the current repo build dir.
# These paths get replaced with relocatable paths or linker / framework flags.
CMake: Generate qmake .prl files This commit also adds a qt_finalize_module function that is called for every Qt module after all link dependencies have been added. Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-12 15:16:55 +00:00
# LIBRARY_SUFFIXES: list of known library extensions, e.g. .so;.a on Linux
CMake: Fix generated content of prl files (again) Apply the same kind of transformations to the contents of the prl files as we do for pri files. Mainly, transform system library paths that are absolute, into link flags to make them relocatable across systems. Also change the Qt frameworks to be linked via the -framework flags instead of via absolute paths. Implementation notes Move the common required functions for both QtFinishPrlFile and QtGenerateLibPri into a common QtGenerateLibHelpers.cmake file. Make sure it's listed as a dependency for the custom commands. Also make sure to pass the necessary input values like possible library prefixes and suffixes, as well as the link flag. Task-number: QTBUG-85240 Task-number: QTBUG-85801 Change-Id: I36f24207f92a1d2ed3ed2d81bb96e4e62d927b6e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-07-30 17:17:09 +00:00
# LIBRARY_PREFIXES: list of known library prefies, e.g. the "lib" in "libz" on on Linux
# LINK_LIBRARY_FLAG: flag used to link a shared library to an executable, e.g. -l on UNIX
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
# IMPLICIT_LINK_DIRECTORIES: list of implicit linker search paths
CMake: Generate qmake .prl files This commit also adds a qt_finalize_module function that is called for every Qt module after all link dependencies have been added. Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-12 15:16:55 +00:00
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
cmake_policy(SET CMP0007 NEW)
CMake: Fix generated content of prl files (again) Apply the same kind of transformations to the contents of the prl files as we do for pri files. Mainly, transform system library paths that are absolute, into link flags to make them relocatable across systems. Also change the Qt frameworks to be linked via the -framework flags instead of via absolute paths. Implementation notes Move the common required functions for both QtFinishPrlFile and QtGenerateLibPri into a common QtGenerateLibHelpers.cmake file. Make sure it's listed as a dependency for the custom commands. Also make sure to pass the necessary input values like possible library prefixes and suffixes, as well as the link flag. Task-number: QTBUG-85240 Task-number: QTBUG-85801 Change-Id: I36f24207f92a1d2ed3ed2d81bb96e4e62d927b6e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-07-30 17:17:09 +00:00
include("${CMAKE_CURRENT_LIST_DIR}/QtGenerateLibHelpers.cmake")
CMake: Generate qmake .prl files This commit also adds a qt_finalize_module function that is called for every Qt module after all link dependencies have been added. Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-12 15:16:55 +00:00
file(STRINGS "${IN_FILE}" lines)
set(content "")
CMake: Fix generated content of prl files (again) Apply the same kind of transformations to the contents of the prl files as we do for pri files. Mainly, transform system library paths that are absolute, into link flags to make them relocatable across systems. Also change the Qt frameworks to be linked via the -framework flags instead of via absolute paths. Implementation notes Move the common required functions for both QtFinishPrlFile and QtGenerateLibPri into a common QtGenerateLibHelpers.cmake file. Make sure it's listed as a dependency for the custom commands. Also make sure to pass the necessary input values like possible library prefixes and suffixes, as well as the link flag. Task-number: QTBUG-85240 Task-number: QTBUG-85801 Change-Id: I36f24207f92a1d2ed3ed2d81bb96e4e62d927b6e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-07-30 17:17:09 +00:00
set(qt_framework_search_path_inserted FALSE)
CMake: Generate qmake .prl files This commit also adds a qt_finalize_module function that is called for every Qt module after all link dependencies have been added. Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-12 15:16:55 +00:00
foreach(line ${lines})
CMake: Write object libs of Qt resources to .prl files Since commit e343affd634 we're creating object libraries for Qt resources in static libraries. Those must be reflected in the generated .prl files for static builds of Qt. In qt_add_resource, we now calculate the install locations of the object files of rcc-generated C++ files and save them in the target property QT_RCC_OBJECTS. This property is then passed to QtFinishPrlFile to write the object file paths to the .prl file. Change-Id: Ic383892d723d02fc91f712bc2dbcbc90babad074 Reviewed-by: Simon Hausmann <hausmann@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-06-16 08:39:01 +00:00
if(line MATCHES "^RCC_OBJECTS = (.*)")
set(rcc_objects ${CMAKE_MATCH_1})
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
elseif(line MATCHES "^QMAKE_PRL_TARGET_PATH_FOR_CMAKE = (.*)")
set(target_library_path "${CMAKE_MATCH_1}")
CMake: Write object libs of Qt resources to .prl files Since commit e343affd634 we're creating object libraries for Qt resources in static libraries. Those must be reflected in the generated .prl files for static builds of Qt. In qt_add_resource, we now calculate the install locations of the object files of rcc-generated C++ files and save them in the target property QT_RCC_OBJECTS. This property is then passed to QtFinishPrlFile to write the object file paths to the .prl file. Change-Id: Ic383892d723d02fc91f712bc2dbcbc90babad074 Reviewed-by: Simon Hausmann <hausmann@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-06-16 08:39:01 +00:00
elseif(line MATCHES "^QMAKE_PRL_LIBS_FOR_CMAKE = (.*)")
CMake: Generate qmake .prl files This commit also adds a qt_finalize_module function that is called for every Qt module after all link dependencies have been added. Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-12 15:16:55 +00:00
unset(adjusted_libs)
foreach(lib ${CMAKE_MATCH_1})
if("${lib}" STREQUAL "")
continue()
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
# Check if the absolute path represents a Qt module located either in Qt's
# $prefix/lib dir, or in the build dir of the repo.
CMake: Generate qmake .prl files This commit also adds a qt_finalize_module function that is called for every Qt module after all link dependencies have been added. Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-12 15:16:55 +00:00
if(IS_ABSOLUTE "${lib}")
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
qt_internal_path_is_relative_to_qt_lib_path(
"${lib}" "${QT_LIB_DIRS}" lib_is_a_qt_module relative_lib)
if(NOT lib_is_a_qt_module)
# It's not a Qt module, extract the library name and prepend an -l to make
# it relocatable.
CMake: Fix generated content of prl files (again) Apply the same kind of transformations to the contents of the prl files as we do for pri files. Mainly, transform system library paths that are absolute, into link flags to make them relocatable across systems. Also change the Qt frameworks to be linked via the -framework flags instead of via absolute paths. Implementation notes Move the common required functions for both QtFinishPrlFile and QtGenerateLibPri into a common QtGenerateLibHelpers.cmake file. Make sure it's listed as a dependency for the custom commands. Also make sure to pass the necessary input values like possible library prefixes and suffixes, as well as the link flag. Task-number: QTBUG-85240 Task-number: QTBUG-85801 Change-Id: I36f24207f92a1d2ed3ed2d81bb96e4e62d927b6e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-07-30 17:17:09 +00:00
qt_transform_absolute_library_paths_to_link_flags(lib_with_link_flag "${lib}")
list(APPEND adjusted_libs "${lib_with_link_flag}")
CMake: Generate qmake .prl files This commit also adds a qt_finalize_module function that is called for every Qt module after all link dependencies have been added. Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-12 15:16:55 +00:00
else()
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
# Is a Qt module.
CMake: Fix generated content of prl files (again) Apply the same kind of transformations to the contents of the prl files as we do for pri files. Mainly, transform system library paths that are absolute, into link flags to make them relocatable across systems. Also change the Qt frameworks to be linked via the -framework flags instead of via absolute paths. Implementation notes Move the common required functions for both QtFinishPrlFile and QtGenerateLibPri into a common QtGenerateLibHelpers.cmake file. Make sure it's listed as a dependency for the custom commands. Also make sure to pass the necessary input values like possible library prefixes and suffixes, as well as the link flag. Task-number: QTBUG-85240 Task-number: QTBUG-85801 Change-Id: I36f24207f92a1d2ed3ed2d81bb96e4e62d927b6e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-07-30 17:17:09 +00:00
# Transform Qt framework paths into -framework flags.
if(relative_lib MATCHES "^(Qt(.+))\\.framework/")
if(NOT qt_framework_search_path_inserted)
set(qt_framework_search_path_inserted TRUE)
list(APPEND adjusted_libs "-F$$[QT_INSTALL_LIBS]")
endif()
list(APPEND adjusted_libs "-framework" "${CMAKE_MATCH_1}")
else()
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
# Not a framework, transform the Qt module into relocatable relative path.
CMake: Fix generated content of prl files (again) Apply the same kind of transformations to the contents of the prl files as we do for pri files. Mainly, transform system library paths that are absolute, into link flags to make them relocatable across systems. Also change the Qt frameworks to be linked via the -framework flags instead of via absolute paths. Implementation notes Move the common required functions for both QtFinishPrlFile and QtGenerateLibPri into a common QtGenerateLibHelpers.cmake file. Make sure it's listed as a dependency for the custom commands. Also make sure to pass the necessary input values like possible library prefixes and suffixes, as well as the link flag. Task-number: QTBUG-85240 Task-number: QTBUG-85801 Change-Id: I36f24207f92a1d2ed3ed2d81bb96e4e62d927b6e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-07-30 17:17:09 +00:00
qt_strip_library_version_suffix(relative_lib "${relative_lib}")
list(APPEND adjusted_libs "$$[QT_INSTALL_LIBS]/${relative_lib}")
endif()
CMake: Generate qmake .prl files This commit also adds a qt_finalize_module function that is called for every Qt module after all link dependencies have been added. Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-12 15:16:55 +00:00
endif()
else()
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
# Not absolute path, most likely a library name or a linker flag.
# If linker flag (like -framework, -lfoo, -pthread, keep it as-is).
CMake: Do not prepend -l to libs starting with dash in prl files For example, we must not prepend -l to -pthread, -framework and -lfoo. Fixes: QTBUG-87760 Change-Id: Ie1bc7a76183c2c4980c519b5f23dde6c47ec85a9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-21 15:50:34 +00:00
if(NOT lib MATCHES "^-")
CMake: Generate qmake .prl files This commit also adds a qt_finalize_module function that is called for every Qt module after all link dependencies have been added. Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-12 15:16:55 +00:00
string(PREPEND lib "-l")
endif()
list(APPEND adjusted_libs "${lib}")
endif()
endforeach()
CMake: Write object libs of Qt resources to .prl files Since commit e343affd634 we're creating object libraries for Qt resources in static libraries. Those must be reflected in the generated .prl files for static builds of Qt. In qt_add_resource, we now calculate the install locations of the object files of rcc-generated C++ files and save them in the target property QT_RCC_OBJECTS. This property is then passed to QtFinishPrlFile to write the object file paths to the .prl file. Change-Id: Ic383892d723d02fc91f712bc2dbcbc90babad074 Reviewed-by: Simon Hausmann <hausmann@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-06-16 08:39:01 +00:00
if(rcc_objects)
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
set(libs_to_prepend ${rcc_objects})
# By default, when qmake processes prl files, it first puts the processed library
# on the link line, followed by all values specified in QMAKE_PRL_LIBS.
# Because we add the resource object files into QMAKE_PRL_LIBS, this means they will
# also appear on the link line after the library.
# This causes issues on Linux because the linker may discard unreferenced symbols from
# the library, which are referenced by the resource object files.
# We can't control the placement of the library in relation to QMAKE_PRL_LIBS, but we
# can add the library one more time in QMAKE_PRL_LIBS, after the object files.
# qmake's UnixMakefileGenerator::findLibraries then takes care of deduplication, which
# keeps the last occurrence of the library on the link line, the one after the object
# files.
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
qt_internal_path_is_relative_to_qt_lib_path(
"${target_library_path}" "${QT_LIB_DIRS}" lib_is_a_qt_module relative_lib)
if(NOT lib_is_a_qt_module)
qt_internal_path_is_relative_to_qt_lib_path(
"${target_library_path}" "${QT_PLUGIN_DIRS}" lib_is_a_qt_plugin relative_lib)
endif()
if(NOT lib_is_a_qt_module AND NOT lib_is_a_qt_plugin)
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
qt_internal_path_is_relative_to_qt_lib_path(
"${target_library_path}" "${QT_QML_DIRS}" lib_is_a_qt_qml_plugin relative_lib)
endif()
if(NOT lib_is_a_qt_module AND NOT lib_is_a_qt_plugin AND NOT lib_is_a_qt_qml_plugin)
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
message(AUTHOR_WARNING
"Could not determine relative path for library ${target_library_path} when "
"generating prl file contents. An absolute path will be embedded, which "
"will cause issues if the Qt installation is relocated.")
list(APPEND libs_to_prepend "${target_library_path}")
else()
set(qmake_lib_path_prefix "$$[QT_PRL_INVALID_QMAKE_VARIABLE]")
if(lib_is_a_qt_module)
set(qmake_lib_path_prefix "$$[QT_INSTALL_LIBS]")
elseif(lib_is_a_qt_plugin)
set(qmake_lib_path_prefix "$$[QT_INSTALL_PLUGINS]")
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
elseif(lib_is_a_qt_qml_plugin)
set(qmake_lib_path_prefix "$$[QT_INSTALL_QML]")
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
endif()
qt_strip_library_version_suffix(relative_lib "${relative_lib}")
list(APPEND libs_to_prepend "${qmake_lib_path_prefix}/${relative_lib}")
endif()
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
list(PREPEND adjusted_libs ${libs_to_prepend})
CMake: Write object libs of Qt resources to .prl files Since commit e343affd634 we're creating object libraries for Qt resources in static libraries. Those must be reflected in the generated .prl files for static builds of Qt. In qt_add_resource, we now calculate the install locations of the object files of rcc-generated C++ files and save them in the target property QT_RCC_OBJECTS. This property is then passed to QtFinishPrlFile to write the object file paths to the .prl file. Change-Id: Ic383892d723d02fc91f712bc2dbcbc90babad074 Reviewed-by: Simon Hausmann <hausmann@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-06-16 08:39:01 +00:00
endif()
CMake: Generate qmake .prl files This commit also adds a qt_finalize_module function that is called for every Qt module after all link dependencies have been added. Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-12 15:16:55 +00:00
list(JOIN adjusted_libs " " adjusted_libs_for_qmake)
string(APPEND content "QMAKE_PRL_LIBS = ${adjusted_libs_for_qmake}\n")
string(APPEND content "QMAKE_PRL_LIBS_FOR_CMAKE = ${adjusted_libs}\n")
else()
string(APPEND content "${line}\n")
endif()
endforeach()
file(WRITE "${OUT_FILE}" "${content}")
CMake: Fix building debug apps with qmake on Windows Our CMake build system only generated working .prl files for the Release configuration in debug_and_release. This caused a linking failure when building a Widgets example that links against qtmain, specifically qtmaind.lib(qtmain_win.cpp.obj) : error LNK2019: unresolved external symbol __imp_CommandLineToArgvW referenced in function WinMain The symbol is located in shell32.dll, which was not linked in, because there was no qtmaind.prl file. The fix to generate per config prl files is a bit complicated, because add_custom_command does not support generator expressions in OUTPUT and DEPENDS. Instead we pre-generate 2 files per config, one with the preliminary prl file content and another file that contains the final prl file path (via generator expression). Then we iterate over all configurations and create custom commands with well known paths, and the final prl file is created by the script called by the command. Amends 06557312d2a030f9ff771488bd6c97690a125a3d Task-number: QTBUG-85240 Change-Id: I413b705bc69732b0cbe1ee8cd089a1aef19365db Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-07-24 18:12:19 +00:00
# Read the prl meta file to find out where should the final prl file be placed,
# Copy it there, if the contents hasn't changed.
file(STRINGS "${IN_META_FILE}" lines)
foreach(line ${lines})
if(line MATCHES "^FINAL_PRL_FILE_PATH = (.*)")
set(final_prl_file_path "${CMAKE_MATCH_1}")
configure_file(
"${OUT_FILE}"
"${final_prl_file_path}"
COPYONLY
)
endif()
endforeach()
Reference in New Issue Copy Permalink