AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
6a873a6edf
qt5base-lts/cmake/QtModuleToolsConfig.cmake.in

31 lines
1.2 KiB
CMake
Raw Normal View History

Export tool config and target files for each relevant module CMake will now generate config and target files for each module that provides tools. As a result, namespaced global targets such as Qt5::moc or Qt5::rcc can be made available. Third party projects that require just these tools, and not the Qt modules themselves, should specify CMAKE_PREFIX_PATH pointing to the installed Qt location, and call find_package(Qt5CoreTools), find_package(Qt5GuiTools), etc. It is also possible to call find_package(Qt5Tools REQUIRED Core Widgets) where the last option is a list of modules whose tools should be imported. Note that all the tools are in the Qt5:: namespace and not in the Qt5CoreTools:: or Qt5WidgetsTools:: namespace. This commit also changes the behavior regarding when to build tools while building Qt itself. When cross compiling Qt (checked via CMAKE_CROSSCOMPILING) or when -DQT_FORCE_FIND_TOOLS=TRUE is passed, tools added by add_qt_tool will always be searched for and not built. In this case the user has to specify the CMake variable QT_HOST_PATH pointing to an installed host Qt location. When not cross compiling, tools added by add_qt_tool are built from source. When building leaf modules (like qtsvg) that require some tool that was built in qtbase (like moc), the module project should contain a find_package(Qt5ToolsCore) call and specify an appropriate CMAKE_PREFIX_PATH so that the tool package is found. Note that because HOST_QT_TOOLS_DIRECTORY was replaced by QT_HOST_PATH, the ensure syncqt code was changed to make it work properly with both qtbase and qtsvg. Here's a list of tools and their module associations: qmake, moc, rcc, tracegen, qfloat16-tables, qlalr -> CoreTools qvkgen -> GuiTools uic -> WidgetTools dbus related tools -> DBusTools Task-number: QTBUG-74134 Change-Id: Ie67d1e2f8de46102b48eca008f0b50caf4fbe3ed Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-10 17:21:22 +00:00
@PACKAGE_INIT@
CMake: Enable NEW policies by CMake version with a global default When a CMake release introduces a new policy that affects most Qt modules, it may be appropriate to make each module aware of that newer CMake version and use the NEW policy without raising the minimum CMake version requirement. To reduce the churn associated with making that change across all Qt modules individually, this change allows it to be updated in a central place (qtbase), but in a way that allows a Qt module to override it in its own .cmake.conf file if required (e.g. to address the issues identified by policy warnings at a later time). The policies are modified at the start of the call to qt_build_repo_begin(). For commands defined by the qtbase module, qtbase needs to be in control of the policy settings at the point where those commands are defined. The above mechanism should not affect the policy settings for these commands, so the various *Config.cmake.in files must not specify policy ranges in a way that a Qt module's .cmake.conf file could influence. Starting with CMake 3.12, policies can be specified as a version range with the cmake_minimum_required() and cmake_policy() commands. All policies introduced in CMake versions up to the upper limit of that range will be set to NEW. The actual version of CMake being used only has to be at least the lower limit of the specified version range. This change uses cmake_minimum_required() rather than cmake_policy() due to the latter not halting further processing upon failure. See the following: https://gitlab.kitware.com/cmake/cmake/-/issues/21557 Task-number: QTBUG-88700 Pick-to: 6.0 Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-30 07:46:49 +00:00
cmake_minimum_required(VERSION @min_new_policy_version@...@max_new_policy_version@)
Make module package depend on its own tool package Also make the tool package depend on all tool packages that correspond to the qt module dependencies. So find_package(Qt5Widgets) implicitly calls find_package(Qt5WidgetTools). And find_package(Qt5WidgetsTools) will call find_package for Qt5GuiTools, and Qt5CoreTools. This enhances the user experience, so that in modules like qtsvg, you don't have to specify both find_package(Qt5Widgets) and find_package(Qt5WidgetsTools), but only the former. Or when cross building, you only need to specify Qt5WidgetTools, to get both Core and Gui tools. Change-Id: Ib1c5173a5b97584a52e144c22e38e90a712f727a Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-29 12:36:25 +00:00
include(CMakeFindDependencyMacro)
Make sure that all dependencies are found before creating tool targets The result of dependency lookup is not taken into account when evaluating tool packages. Check for <ToolPackage>_FOUND before creating the tool targets that belong to the tool package. Adjust the tool package lookup that the dependencies always affect the lookup result even if we avoided creating targets by setting QT_NO_CREATE_TARGETS. Pick-to: 6.5 6.5.0 Change-Id: Ia95c9c71370becc639ed8a9db026aed2f93959b4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-07 13:23:29 +00:00
# Find required dependencies, if any.
if(EXISTS "${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@Dependencies.cmake")
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@Dependencies.cmake")
endif()
# If *Dependencies.cmake exists, the variable value will be defined there.
# Don't override it in that case.
if(NOT DEFINED "@INSTALL_CMAKE_NAMESPACE@@target@_FOUND")
set("@INSTALL_CMAKE_NAMESPACE@@target@_FOUND" TRUE)
endif()
Make module package depend on its own tool package Also make the tool package depend on all tool packages that correspond to the qt module dependencies. So find_package(Qt5Widgets) implicitly calls find_package(Qt5WidgetTools). And find_package(Qt5WidgetsTools) will call find_package for Qt5GuiTools, and Qt5CoreTools. This enhances the user experience, so that in modules like qtsvg, you don't have to specify both find_package(Qt5Widgets) and find_package(Qt5WidgetsTools), but only the former. Or when cross building, you only need to specify Qt5WidgetTools, to get both Core and Gui tools. Change-Id: Ib1c5173a5b97584a52e144c22e38e90a712f727a Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-29 12:36:25 +00:00
Make sure that all dependencies are found before creating tool targets The result of dependency lookup is not taken into account when evaluating tool packages. Check for <ToolPackage>_FOUND before creating the tool targets that belong to the tool package. Adjust the tool package lookup that the dependencies always affect the lookup result even if we avoided creating targets by setting QT_NO_CREATE_TARGETS. Pick-to: 6.5 6.5.0 Change-Id: Ia95c9c71370becc639ed8a9db026aed2f93959b4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-07 13:23:29 +00:00
if (NOT QT_NO_CREATE_TARGETS AND @INSTALL_CMAKE_NAMESPACE@@target@_FOUND)
Allow to build examples as standalone project Create CMake config files which can be used from the very same CMake project. These CMake config files simply do not create any targets, controlled via the QT_NO_CREATE_TARGETS. This patch also allows to build qtbase.git:examples as a standalone project, against an already-built Qt. Ran this: ag -s "QT " examples -l -0 | xargs -0 -n 1 .../util/cmake/pro2cmake.py --is-example Task-number: QTBUG-74713 Change-Id: I44cce5a4048618b30f890c5b789592c227a8b47d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-04 15:08:47 +00:00
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@Targets.cmake")
CMake: Generate *AdditionalTargetInfo.cmake for tools This ensures that we have the configuration-independent IMPORTED_* properties set on tools. Fixes: QTBUG-86893 Change-Id: I2b772c21341e6e4631379d4a5a99580ec96909ed Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-25 10:18:58 +00:00
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@AdditionalTargetInfo.cmake")
CMake: Fix creation of versionless targets for tools We can't use qt_internal_export_modern_cmake_config_targets_file for executables like tools, because it's not possible to use INTERFACE_LINK_LIBRARIES with executables like you can with libraries. We also can't create aliases to non-global imported targets. Instead create new imported executable targets, fish out the imported location, and assign it to the versionless targets. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Task-number: QTBUG-75984 Change-Id: I6a3c9c67ef4699c72a6c9a627c63158dfd6557f8 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-12-05 12:54:07 +00:00
if(NOT QT_NO_CREATE_VERSIONLESS_TARGETS)
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@VersionlessTargets.cmake")
endif()
Allow to build examples as standalone project Create CMake config files which can be used from the very same CMake project. These CMake config files simply do not create any targets, controlled via the QT_NO_CREATE_TARGETS. This patch also allows to build qtbase.git:examples as a standalone project, against an already-built Qt. Ran this: ag -s "QT " examples -l -0 | xargs -0 -n 1 .../util/cmake/pro2cmake.py --is-example Task-number: QTBUG-74713 Change-Id: I44cce5a4048618b30f890c5b789592c227a8b47d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-04 15:08:47 +00:00
endif()
Export tool config and target files for each relevant module CMake will now generate config and target files for each module that provides tools. As a result, namespaced global targets such as Qt5::moc or Qt5::rcc can be made available. Third party projects that require just these tools, and not the Qt modules themselves, should specify CMAKE_PREFIX_PATH pointing to the installed Qt location, and call find_package(Qt5CoreTools), find_package(Qt5GuiTools), etc. It is also possible to call find_package(Qt5Tools REQUIRED Core Widgets) where the last option is a list of modules whose tools should be imported. Note that all the tools are in the Qt5:: namespace and not in the Qt5CoreTools:: or Qt5WidgetsTools:: namespace. This commit also changes the behavior regarding when to build tools while building Qt itself. When cross compiling Qt (checked via CMAKE_CROSSCOMPILING) or when -DQT_FORCE_FIND_TOOLS=TRUE is passed, tools added by add_qt_tool will always be searched for and not built. In this case the user has to specify the CMake variable QT_HOST_PATH pointing to an installed host Qt location. When not cross compiling, tools added by add_qt_tool are built from source. When building leaf modules (like qtsvg) that require some tool that was built in qtbase (like moc), the module project should contain a find_package(Qt5ToolsCore) call and specify an appropriate CMAKE_PREFIX_PATH so that the tool package is found. Note that because HOST_QT_TOOLS_DIRECTORY was replaced by QT_HOST_PATH, the ensure syncqt code was changed to make it work properly with both qtbase and qtsvg. Here's a list of tools and their module associations: qmake, moc, rcc, tracegen, qfloat16-tables, qlalr -> CoreTools qvkgen -> GuiTools uic -> WidgetTools dbus related tools -> DBusTools Task-number: QTBUG-74134 Change-Id: Ie67d1e2f8de46102b48eca008f0b50caf4fbe3ed Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-10 17:21:22 +00:00
CMake: Support installing extra cmake files for tools Add an EXTRA_CMAKE_FILES argument to qt_internal_add_tool() that allows tools to install an additional Macro.cmake file. This is modelled after similar functionality in qt_internal_add_module. Task-number: QTBUG-87870 Change-Id: I80838b8966f1018fdd379b1da877b6bc418de075 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-27 16:35:58 +00:00
foreach(extra_cmake_include @extra_cmake_includes@)
include("${CMAKE_CURRENT_LIST_DIR}/${extra_cmake_include}")
endforeach()
Export tool config and target files for each relevant module CMake will now generate config and target files for each module that provides tools. As a result, namespaced global targets such as Qt5::moc or Qt5::rcc can be made available. Third party projects that require just these tools, and not the Qt modules themselves, should specify CMAKE_PREFIX_PATH pointing to the installed Qt location, and call find_package(Qt5CoreTools), find_package(Qt5GuiTools), etc. It is also possible to call find_package(Qt5Tools REQUIRED Core Widgets) where the last option is a list of modules whose tools should be imported. Note that all the tools are in the Qt5:: namespace and not in the Qt5CoreTools:: or Qt5WidgetsTools:: namespace. This commit also changes the behavior regarding when to build tools while building Qt itself. When cross compiling Qt (checked via CMAKE_CROSSCOMPILING) or when -DQT_FORCE_FIND_TOOLS=TRUE is passed, tools added by add_qt_tool will always be searched for and not built. In this case the user has to specify the CMake variable QT_HOST_PATH pointing to an installed host Qt location. When not cross compiling, tools added by add_qt_tool are built from source. When building leaf modules (like qtsvg) that require some tool that was built in qtbase (like moc), the module project should contain a find_package(Qt5ToolsCore) call and specify an appropriate CMAKE_PREFIX_PATH so that the tool package is found. Note that because HOST_QT_TOOLS_DIRECTORY was replaced by QT_HOST_PATH, the ensure syncqt code was changed to make it work properly with both qtbase and qtsvg. Here's a list of tools and their module associations: qmake, moc, rcc, tracegen, qfloat16-tables, qlalr -> CoreTools qvkgen -> GuiTools uic -> WidgetTools dbus related tools -> DBusTools Task-number: QTBUG-74134 Change-Id: Ie67d1e2f8de46102b48eca008f0b50caf4fbe3ed Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-10 17:21:22 +00:00
@extra_cmake_statements@
Reference in New Issue Copy Permalink