summaryrefslogtreecommitdiffstats
path: root/cmake/QtPublicTargetHelpers.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Remove TODOs related to checking CMake 3.21 features post-releaseCraig Scott2021-09-181-2/+0
| | | | | | | | | | | These TODOs were left as a marker to be checked once the official CMake 3.21.0 release was made. The things they refer to were included in the CMake 3.21.0 release, so the TODOs can be removed. Fixes: QTBUG-94528 Pick-to: 6.2 Change-Id: I769605de85df657ad056123e787ec9849b77e42f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Call MinGW's ld with -Bstatic when requesting static runtime linkageJoerg Bornemann2021-08-271-1/+1
| | | | | | | | | | | The -static argument we used before is supported by ld, but not lld. The latter requires --static or -Bstatic. Use -Bstatic, which is supported by both. Pick-to: 6.2 Fixes: QTBUG-89549 Change-Id: I3c3069661bf4cd20e3298aff4714163b7419d3ef Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Use correct MSVC runtime library for Qt object librariesAlexandru Croitor2021-07-091-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | If Qt was configured with -static-runtime which implies MultiThreaded -MT flag, the plugin initializer object libraries were still compiled with the default -MD flag. When an application linked to Qt, that caused linking to fail with mismatched symbol errors between the application symbols and the plugin initializer object library symbols. Make sure to set the MSVC_RUNTIME_LIBRARY property on both plugin initializer and resource object libraries, depending on the value of QT_FEATURE_static_runtime. We did set the property for resources added by qt_internal_add_resource, but not for the resource created by the public qt6_add_resources counterpart. Pick-to: 6.2 Fixes: QTBUG-95043 Change-Id: Ia543cd0241db94a12080be2655ad420fe9ad3f24 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Make QT_HAVE_LINK_ORDER_MATTERS INTERNAL to hide from GUIAlexey Edelev2021-07-081-2/+2
| | | | | | | | | Hide QT_HAVE_LINK_ORDER_MATTERS from GUI like QtCreator's CMake configurator. Pick-to: 6.1 6.2 Change-Id: I9591092f0902ad17ff260a1ca4494239a7acf6fa Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Use target_link_options to propagate object librariesAlexey Edelev2021-07-021-3/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | target_link_options are placed by CMake at the beginning of a linker line. This gives us an opportunity to use the function to propagate object libraries. This change adds one more check in the root Config.cmake file. If CMP0099 policy is enabled, CMake enables propagating of the linking options when linking two static libraries using the PRIVATE linking visibility, so we can rely on the correct linking order and expect object libraries to be propagated. Note that on the platforms where cmake version is higher than 3.16 Qt uses CMP0099 NEW in functions like qt_add_executable. This means that at the moment of creating an executable target the TARGET_POLICY genex will also be NEW, so we do not take into the account the user defined CMP0099. If the CMP0099 policy is not available for a certain CMake version we skip the TARGET_POLICY check and simply disable propagation of the object libraries using target_link_options for both user and Qt libraries. This is applicable for the CMake versions 3.16 and less. Linking approaches have the following priorities(from higher to lower) after this change: - target_link_libraries - works if link order matters not or CMake version greater equal 3.21. - target_link_options - works if CMP0099 is set to NEW by user or if the CMake version is greater than or equal to 3.17 and an executable is created using Qt functions. - object library finalizer - works if CMake version is greater equal 3.19 or qt6_finalize_target is called explicitly. - target_sources - is used when all the other approaches could not be used. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Amends 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Change-Id: I14f88caeb04e357191c840abeab89b03e210b796 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Pierce through LINK_ONLY deps in finalizer dep traversalAlexandru Croitor2021-06-291-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ensure that the finalizer approach of __qt_internal_propagate_object_library considers $<LINK_ONLY:> libraries when traversing the dependencies of a target. The issue was discovered when using the Quick.Shapes QML module in a static build. The module has both a backing library and a plugin. The backing library has some resource objects associated with it. When the targets are exported, the plugin INTERFACE_LINK_LIBRARIES has a $<LINK_ONLY:QuickShapes> dependency. This ensures that the library will be linked, but depending on which linking approach in __qt_internal_propagate_object_library is used, the resources might not be linked to the final executable. The resources are linked correctly when using the target_link_libraries approach, but not when using the finalizer or target_sources approach. This change fixes the finalizer approach, but the target_sources approach is still broken. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Pick-to: 6.2 Change-Id: Ifbb91a17d388c3dc4263e17ec0d3bd5627b57cb4 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Disable finalizers by default for the non-ld linkersAlexey Edelev2021-06-191-0/+4
| | | | | | | | | | Check if link order matters before use the object library finalizer. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Change-Id: Ie996bc175ebea36ccda1bb2fe388ae3b7fcde395 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Move the linking logic of the object libraries to a common functionAlexey Edelev2021-06-181-38/+40
| | | | | | | | | | | | | | | | | | | The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove target specific flags from the linker capabilities checkAlexey Edelev2021-06-161-31/+16
| | | | | | | | | | | | | Remove target specific flags from static_link_order. Move the check to the common config.tests folder. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I1368075ec6bd1e743b2b89fd93143df38a278ec2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Check the impact of static link order for user projectsAlexey Edelev2021-06-161-1/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Promote all targets to global within a scope when possibleAlexandru Croitor2021-06-161-1/+35
| | | | | | | | | | | | | | | | | | | | | | | | CMake 3.21 introduced a new IMPORTED_TARGETS directory property which we can use to promote all imported targets within a scope to be global. This would cover transitive non-Qt imported targets which the Qt build system does not know about and is thus a more complete solution compared to promoting only Qt targets. Run a finalizer at the end of the directory scope where find_package(Qt6) is called to promote all imported targets within that scope to global (when requested). The old promotion method is disabled when the CMake version is new enough. Pick-to: 6.2 Task-number: QTBUG-92878 Task-number: QTBUG-94528 Change-Id: I533a3bd4186eba652f878ddd72c76118c2fd8bae Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Allow promoting the Qt libraries to be global targetsAlexandru Croitor2021-06-161-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Collect resource objects of plugins and their dependencies in finalizerAlexey Edelev2021-06-031-2/+32
| | | | | | | | | | | | | Resource objects might be linked to plugins. Since some plugins may be present in LINK_LIBRARIES as the complex genexes, need to collect them explicitly and iterate over plugin targets to find resource object libraries that need to be exposed to end-point target executable. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Change-Id: Icd85f54f7bf9d1b7e3382caa5d9aa62449b6adb8 Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Do not get LINK_LIBRARY of the interface librariesAlexey Edelev2021-06-011-1/+7
| | | | | | | | | | Avoid getting the LINK_LIBRARY property of the interface libraries when calling a resource object finalizer. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Change-Id: I19d625a927c66994902f5c89e6c82183c94af91e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Rework resource finalizer approachAlexey Edelev2021-05-311-10/+40
| | | | | | | | | | | | | | | | In the previous implementation of the resource object finalizer, we used the name of the resource object library without namespaces when recording it in the resource libraries list. This causes an issue when we or users export resource targets. This approach marks resource object libraries with the exporting property instead of collecting resource targets when creating them. Amends 19e789bace887105badae83c0a79429bbf8e8221 Change-Id: I8596815921f2c681ddd78d9b2e9a4e1cafe5000b Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Implement propagation of object files to the end-point executableAlexey Edelev2021-05-271-0/+34
| | | | | | | | | | | | | | | | | | | | This proposal collects all the resource objects to the qt-specific property of the static libraries. This is done to avoid littering of other static libraries and put resource object files to the source part of the linker line when linking the end-point executable. The way we link object resource libraries is changed back to the target_link_libraries approach as we may omit using finalizers with linkers other than ld. Users may enforce finalizers by calling the qt6_enable_resource_objects_finalizer_mode function if need. Refactor tests related to the static resources. Amends ddaa7150d85624ab545ccfe098fe8b2d18241940 Task-number: QTBUG-93002 Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Make qt_internal_walk_libs available in public projectsAlexandru Croitor2021-05-111-0/+16
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-21 08:55:32 +0000