AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
65e977f062
qt5base-lts/cmake/QtModuleConfig.cmake.in

146 lines
6.9 KiB
CMake
Raw Normal View History

Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +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@)
cmake: Make find_package(Qt5 ...) work properly Introduce a new cached variable INSTALL_CMAKE_NAMESPACE for defining the prefix used for CMake config files (c.f. "${PREFIX}Core/${PREFIX}CoreConfig.cmake") Also make sure to `find_dependency(...)` the required packages inside the individual CMake config files. I.e. in Qt5WidgetsConfig.cmake, search for Qt5Core, etc. pp.. Change-Id: Idc027925fe9d5323091c4853803ad5ce44b1afc6 Reviewed-by: Jean-Michaël Celerier <jean-michael.celerier@kdab.com> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-02-11 10:34:35 +00:00
include(CMakeFindDependencyMacro)
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
cmake: Make find_package(Qt5 ...) work properly Introduce a new cached variable INSTALL_CMAKE_NAMESPACE for defining the prefix used for CMake config files (c.f. "${PREFIX}Core/${PREFIX}CoreConfig.cmake") Also make sure to `find_dependency(...)` the required packages inside the individual CMake config files. I.e. in Qt5WidgetsConfig.cmake, search for Qt5Core, etc. pp.. Change-Id: Idc027925fe9d5323091c4853803ad5ce44b1afc6 Reviewed-by: Jean-Michaël Celerier <jean-michael.celerier@kdab.com> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-02-11 10:34:35 +00:00
get_filename_component(_import_prefix "${CMAKE_CURRENT_LIST_FILE}" PATH)
get_filename_component(_import_prefix "${_import_prefix}" REALPATH)
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
Propagate QT_CMAKE_EXPORT_NAMESPACE via QtCore package QT_CMAKE_EXPORT_NAMESPACE is used by the Qt packages to make features available to the consuming CMake project. The value was moved to the BuildInternals Config file, but that's wrong because consuming applications not including the BuildInternals component would fail to use any other Qt package. Move QT_CMAKE_EXPORT_NAMESPACE to be propagated with QtCore package again. Amends 9542e78525b422159406d8fa63e30dcd0f926411. Change-Id: I9841ac8c2828b00c0111d59e8976c889554e0ce1 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-05-16 09:34:06 +00:00
# Extra cmake code begin
@extra_cmake_code@
# Extra cmake code end
Fix linking of examples Provide add_qt_gui_executable() as function in our public API that takes care of automaticWinMain linkage. We can use this in the future to encapsulate similarplatform-specific behavior and adjustments, such as module generation onAndroid. In order for the examples to see the function in Qt5CoreMacros, three more additional fixes were required: * Do the build_repo_end() call _before_ attempting to build the examples, as we need the build_repo_end() to include QtPostProcess and complete the creation of all the target config files. Otherwise the find_package() calls in the examples see something incomplete. * Add more QT_NO_CREATE_TARGET guards * Always call find_dependency on the dependencies, regardless of the target creation mode. This way a find_package(Qt5 COMPONENTS Widgets) will still load Qt5CoreMacros. Change-Id: I03ce856e2f4312a050fe8043b8331cbe8a6c93e6 Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-11 13:46:31 +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")
CMake: Introduce QT_DEBUG_FIND_PACKAGE for troubleshooting When a Qt component or dependency is not found, we will now show a message that the user can reconfigure the project with -DQT_DEBUG_FIND_PACKAGE=ON. If the option is enabled, various variables that find_package uses to find packages (like CMAKE_PREFIX_PATH, CMAKE_FIND_ROOT_PATH) will be recorded before each find_package / find_dependency call that is executed in any of the Qt package files. If any find_package call fails (a package has its _FOUND variable set to 0), the values of all those recorded variables will be shown. This is useful to troubleshoot issues, especially when cross-compiling, without having to manually modify the various Config files. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I3654960597911bd704fbe3c419bcae347ab739a9 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-14 15:00:56 +00:00
_qt_internal_suggest_dependency_debugging(@target@
CMake: Suggest hints on how to debug missing packages Depending on CMake version suggest usage of either --debug-find-pkg or CMAKE_FIND_DEBUG_MODE to help troubleshoot why dependent packages are not found. To achieve that, append the hint message to the _NOT_FOUND_MESSAGE. To ensure it works for qt dependencies, and not only tool and 3rd party dependencies, _qt_internal_find_qt_dependencies is modified to set variable names infixed by the target name, so the name is consistent with the other dependency lookup functions. The check and message are also added when a Qt6 component is not found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I4ef23d1c53ac8e04eb72c260d6860c1eeec8d7a3 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-14 13:28:12 +00:00
__qt_@target@_pkg ${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE)
Fix linking of examples Provide add_qt_gui_executable() as function in our public API that takes care of automaticWinMain linkage. We can use this in the future to encapsulate similarplatform-specific behavior and adjustments, such as module generation onAndroid. In order for the examples to see the function in Qt5CoreMacros, three more additional fixes were required: * Do the build_repo_end() call _before_ attempting to build the examples, as we need the build_repo_end() to include QtPostProcess and complete the creation of all the target config files. Otherwise the find_package() calls in the examples see something incomplete. * Add more QT_NO_CREATE_TARGET guards * Always call find_dependency on the dependencies, regardless of the target creation mode. This way a find_package(Qt5 COMPONENTS Widgets) will still load Qt5CoreMacros. Change-Id: I03ce856e2f4312a050fe8043b8331cbe8a6c93e6 Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-11 13:46:31 +00:00
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
Revert "Revert "CMake: Fix usage of find_dependency()"" ...and fix the build errors the original change caused. This reverts commit 127fb8bb5587db52216d0ac934f3111170a7cbe3. Change-Id: I4006b32734a51c5d101dd73c957f81d2a0f84ba1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-14 07:06:58 +00:00
# If *ConfigDependencies.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()
CMake: Don't create targets if dependencies are not found If one of the dependencies in QtFooModuleDependencies.cmake is not found, QtFoo_FOUND will be set to False by find_dependency. In that case, we should not create imported targets that belong to that package. It would be misleading for projects that do target existence checks instead of package_FOUND checks as well as generally being incorrect. The created imported targets might be referencing other targets that would not exist. Pick-to: 6.2 Fixes: QTBUG-97896 Change-Id: I09198aa3f19be047b27c29329b6e62c30fa09dc0 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Craig Scott <craig.scott@qt.io>
2021-11-01 09:41:11 +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: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@AdditionalTargetInfo.cmake")
Add support for evaluating genexes when exporting custom target props Properties specified in EXPORT_PROPERTIES have their values exported verbatim, without evaluating generator expression they might contain. This limitation is removed by the introduced functions. They collect properties that needs to be exported and evaluate generator expressions inside the properties using file(GENERATE) before exporting them. The functions generate the ExtraProperties.cmake file that contains set_property calls with exported properties and corresponding values. Change-Id: If32c30a82a62e8bd48bb91f3df21ff2ad8d07243 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-05-13 16:24:22 +00:00
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@ExtraProperties.cmake"
OPTIONAL)
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()
CMake: Provide old style CMake variables for target info This change provides the following per-module variables Qt6Widgets_LIBRARIES, Qt6Widgets_INCLUDE_DIRS, Qt6Widgets_DEFINITIONS, Qt6Widgets_COMPILE_DEFINITIONS, Qt6Widgets_PRIVATE_INCLUDE_DIRS. These are deprecated and are only intended for easier porting from Qt5 to Qt6. Qt consumers should instead rely on the Qt module targets e.g target_link_libraries(app PRIVATE Qt6::Widgets) Note that the variable contents includes transitive values for everything except the _LIBRARIES variant. So Qt6Widgets_INCLUDE_DIRS will contain values for Widgets, Gui and Core. Qt6Widgets_LIBRARIES only contains a value like Qt6::Widgets, and when that is used in target_link_libraries(), CMake will take care of the transitivity. Change-Id: I625e25aab7ba5eaf14de1dc76ba2a1a0c85e6226 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-07-14 16:08:07 +00:00
# DEPRECATED
# Provide old style variables for includes, compile definitions, etc.
# These variables are deprecated and only provided on a best-effort basis to facilitate porting.
# Consider using target_link_libraries(app PRIVATE @QT_CMAKE_EXPORT_NAMESPACE@@target@) instead.
set(@QT_CMAKE_EXPORT_NAMESPACE@@target@_LIBRARIES "@QT_CMAKE_EXPORT_NAMESPACE@::@target@")
get_target_property(_@QT_CMAKE_EXPORT_NAMESPACE@@target@_OWN_INCLUDE_DIRS
@QT_CMAKE_EXPORT_NAMESPACE@::@target@ INTERFACE_INCLUDE_DIRECTORIES)
if(NOT _@QT_CMAKE_EXPORT_NAMESPACE@@target@_OWN_INCLUDE_DIRS)
set(_@QT_CMAKE_EXPORT_NAMESPACE@@target@_OWN_INCLUDE_DIRS "")
endif()
if(TARGET @QT_CMAKE_EXPORT_NAMESPACE@::@target@Private)
get_target_property(_@QT_CMAKE_EXPORT_NAMESPACE@@target@_OWN_PRIVATE_INCLUDE_DIRS
@QT_CMAKE_EXPORT_NAMESPACE@::@target@Private INTERFACE_INCLUDE_DIRECTORIES)
if(NOT _@QT_CMAKE_EXPORT_NAMESPACE@@target@_OWN_PRIVATE_INCLUDE_DIRS)
set(_@QT_CMAKE_EXPORT_NAMESPACE@@target@_OWN_PRIVATE_INCLUDE_DIRS "")
endif()
endif()
get_target_property(@QT_CMAKE_EXPORT_NAMESPACE@@target@_DEFINITIONS
@QT_CMAKE_EXPORT_NAMESPACE@::@target@ INTERFACE_COMPILE_DEFINITIONS)
if(NOT @QT_CMAKE_EXPORT_NAMESPACE@@target@_DEFINITIONS)
set(@QT_CMAKE_EXPORT_NAMESPACE@@target@_DEFINITIONS "")
else()
list(TRANSFORM @QT_CMAKE_EXPORT_NAMESPACE@@target@_DEFINITIONS PREPEND "-D")
endif()
get_target_property(@QT_CMAKE_EXPORT_NAMESPACE@@target@_COMPILE_DEFINITIONS
@QT_CMAKE_EXPORT_NAMESPACE@::@target@ INTERFACE_COMPILE_DEFINITIONS)
if(NOT @QT_CMAKE_EXPORT_NAMESPACE@@target@_COMPILE_DEFINITIONS)
set(@QT_CMAKE_EXPORT_NAMESPACE@@target@_COMPILE_DEFINITIONS "")
endif()
set(@QT_CMAKE_EXPORT_NAMESPACE@@target@_INCLUDE_DIRS
${_@QT_CMAKE_EXPORT_NAMESPACE@@target@_OWN_INCLUDE_DIRS})
set(@QT_CMAKE_EXPORT_NAMESPACE@@target@_PRIVATE_INCLUDE_DIRS
${_@QT_CMAKE_EXPORT_NAMESPACE@@target@_OWN_PRIVATE_INCLUDE_DIRS})
foreach(_module_dep ${_@QT_CMAKE_EXPORT_NAMESPACE@@target@_MODULE_DEPENDENCIES})
Do not collect the Private module dependencies values in public variables Qt ModuleConfig.cmake files set variables like <package>_INCLUDE_DIRS, <package>_DEFINITIONS, etc., which can be used by user projects to acquire the module related information. These variables also accumulate information from Qt Module dependencies. Since we do not separate the Private and regular modules in dependency list, the resulting variables contain values from both. This change puts the information from Private dependencies to the variables of Private module. The exception is PRIVATE_INCLUDE_DIRS which will contain include directories from Private dependencies for non-Private module too. Fixes: QTBUG-118462 Change-Id: I51e6d63651ed1913005064c90f77eba219cf60ea Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-10-24 15:48:55 +00:00
if(_module_dep MATCHES ".+Private$")
set(_private_suffix "Private")
else()
set(_private_suffix "")
endif()
list(APPEND @QT_CMAKE_EXPORT_NAMESPACE@@target@${_private_suffix}_INCLUDE_DIRS
CMake: Provide old style CMake variables for target info This change provides the following per-module variables Qt6Widgets_LIBRARIES, Qt6Widgets_INCLUDE_DIRS, Qt6Widgets_DEFINITIONS, Qt6Widgets_COMPILE_DEFINITIONS, Qt6Widgets_PRIVATE_INCLUDE_DIRS. These are deprecated and are only intended for easier porting from Qt5 to Qt6. Qt consumers should instead rely on the Qt module targets e.g target_link_libraries(app PRIVATE Qt6::Widgets) Note that the variable contents includes transitive values for everything except the _LIBRARIES variant. So Qt6Widgets_INCLUDE_DIRS will contain values for Widgets, Gui and Core. Qt6Widgets_LIBRARIES only contains a value like Qt6::Widgets, and when that is used in target_link_libraries(), CMake will take care of the transitivity. Change-Id: I625e25aab7ba5eaf14de1dc76ba2a1a0c85e6226 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-07-14 16:08:07 +00:00
${@QT_CMAKE_EXPORT_NAMESPACE@${_module_dep}_INCLUDE_DIRS})
Do not collect the Private module dependencies values in public variables Qt ModuleConfig.cmake files set variables like <package>_INCLUDE_DIRS, <package>_DEFINITIONS, etc., which can be used by user projects to acquire the module related information. These variables also accumulate information from Qt Module dependencies. Since we do not separate the Private and regular modules in dependency list, the resulting variables contain values from both. This change puts the information from Private dependencies to the variables of Private module. The exception is PRIVATE_INCLUDE_DIRS which will contain include directories from Private dependencies for non-Private module too. Fixes: QTBUG-118462 Change-Id: I51e6d63651ed1913005064c90f77eba219cf60ea Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-10-24 15:48:55 +00:00
list(APPEND @QT_CMAKE_EXPORT_NAMESPACE@@target@${_private_suffix}_PRIVATE_INCLUDE_DIRS
CMake: Provide old style CMake variables for target info This change provides the following per-module variables Qt6Widgets_LIBRARIES, Qt6Widgets_INCLUDE_DIRS, Qt6Widgets_DEFINITIONS, Qt6Widgets_COMPILE_DEFINITIONS, Qt6Widgets_PRIVATE_INCLUDE_DIRS. These are deprecated and are only intended for easier porting from Qt5 to Qt6. Qt consumers should instead rely on the Qt module targets e.g target_link_libraries(app PRIVATE Qt6::Widgets) Note that the variable contents includes transitive values for everything except the _LIBRARIES variant. So Qt6Widgets_INCLUDE_DIRS will contain values for Widgets, Gui and Core. Qt6Widgets_LIBRARIES only contains a value like Qt6::Widgets, and when that is used in target_link_libraries(), CMake will take care of the transitivity. Change-Id: I625e25aab7ba5eaf14de1dc76ba2a1a0c85e6226 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-07-14 16:08:07 +00:00
${@QT_CMAKE_EXPORT_NAMESPACE@${_module_dep}_PRIVATE_INCLUDE_DIRS})
Do not collect the Private module dependencies values in public variables Qt ModuleConfig.cmake files set variables like <package>_INCLUDE_DIRS, <package>_DEFINITIONS, etc., which can be used by user projects to acquire the module related information. These variables also accumulate information from Qt Module dependencies. Since we do not separate the Private and regular modules in dependency list, the resulting variables contain values from both. This change puts the information from Private dependencies to the variables of Private module. The exception is PRIVATE_INCLUDE_DIRS which will contain include directories from Private dependencies for non-Private module too. Fixes: QTBUG-118462 Change-Id: I51e6d63651ed1913005064c90f77eba219cf60ea Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-10-24 15:48:55 +00:00
if(_private_suffix)
list(APPEND @QT_CMAKE_EXPORT_NAMESPACE@@target@_PRIVATE_INCLUDE_DIRS
${@QT_CMAKE_EXPORT_NAMESPACE@${_module_dep}_PRIVATE_INCLUDE_DIRS})
endif()
list(APPEND @QT_CMAKE_EXPORT_NAMESPACE@@target@${_private_suffix}_DEFINITIONS
CMake: Provide old style CMake variables for target info This change provides the following per-module variables Qt6Widgets_LIBRARIES, Qt6Widgets_INCLUDE_DIRS, Qt6Widgets_DEFINITIONS, Qt6Widgets_COMPILE_DEFINITIONS, Qt6Widgets_PRIVATE_INCLUDE_DIRS. These are deprecated and are only intended for easier porting from Qt5 to Qt6. Qt consumers should instead rely on the Qt module targets e.g target_link_libraries(app PRIVATE Qt6::Widgets) Note that the variable contents includes transitive values for everything except the _LIBRARIES variant. So Qt6Widgets_INCLUDE_DIRS will contain values for Widgets, Gui and Core. Qt6Widgets_LIBRARIES only contains a value like Qt6::Widgets, and when that is used in target_link_libraries(), CMake will take care of the transitivity. Change-Id: I625e25aab7ba5eaf14de1dc76ba2a1a0c85e6226 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-07-14 16:08:07 +00:00
${@QT_CMAKE_EXPORT_NAMESPACE@${_module_dep}_DEFINITIONS})
Do not collect the Private module dependencies values in public variables Qt ModuleConfig.cmake files set variables like <package>_INCLUDE_DIRS, <package>_DEFINITIONS, etc., which can be used by user projects to acquire the module related information. These variables also accumulate information from Qt Module dependencies. Since we do not separate the Private and regular modules in dependency list, the resulting variables contain values from both. This change puts the information from Private dependencies to the variables of Private module. The exception is PRIVATE_INCLUDE_DIRS which will contain include directories from Private dependencies for non-Private module too. Fixes: QTBUG-118462 Change-Id: I51e6d63651ed1913005064c90f77eba219cf60ea Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-10-24 15:48:55 +00:00
list(APPEND @QT_CMAKE_EXPORT_NAMESPACE@@target@${_private_suffix}_COMPILE_DEFINITIONS
CMake: Provide old style CMake variables for target info This change provides the following per-module variables Qt6Widgets_LIBRARIES, Qt6Widgets_INCLUDE_DIRS, Qt6Widgets_DEFINITIONS, Qt6Widgets_COMPILE_DEFINITIONS, Qt6Widgets_PRIVATE_INCLUDE_DIRS. These are deprecated and are only intended for easier porting from Qt5 to Qt6. Qt consumers should instead rely on the Qt module targets e.g target_link_libraries(app PRIVATE Qt6::Widgets) Note that the variable contents includes transitive values for everything except the _LIBRARIES variant. So Qt6Widgets_INCLUDE_DIRS will contain values for Widgets, Gui and Core. Qt6Widgets_LIBRARIES only contains a value like Qt6::Widgets, and when that is used in target_link_libraries(), CMake will take care of the transitivity. Change-Id: I625e25aab7ba5eaf14de1dc76ba2a1a0c85e6226 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-07-14 16:08:07 +00:00
${@QT_CMAKE_EXPORT_NAMESPACE@${_module_dep}_COMPILE_DEFINITIONS})
endforeach()
Do not collect the Private module dependencies values in public variables Qt ModuleConfig.cmake files set variables like <package>_INCLUDE_DIRS, <package>_DEFINITIONS, etc., which can be used by user projects to acquire the module related information. These variables also accumulate information from Qt Module dependencies. Since we do not separate the Private and regular modules in dependency list, the resulting variables contain values from both. This change puts the information from Private dependencies to the variables of Private module. The exception is PRIVATE_INCLUDE_DIRS which will contain include directories from Private dependencies for non-Private module too. Fixes: QTBUG-118462 Change-Id: I51e6d63651ed1913005064c90f77eba219cf60ea Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-10-24 15:48:55 +00:00
unset(_private_suffix)
CMake: Provide old style CMake variables for target info This change provides the following per-module variables Qt6Widgets_LIBRARIES, Qt6Widgets_INCLUDE_DIRS, Qt6Widgets_DEFINITIONS, Qt6Widgets_COMPILE_DEFINITIONS, Qt6Widgets_PRIVATE_INCLUDE_DIRS. These are deprecated and are only intended for easier porting from Qt5 to Qt6. Qt consumers should instead rely on the Qt module targets e.g target_link_libraries(app PRIVATE Qt6::Widgets) Note that the variable contents includes transitive values for everything except the _LIBRARIES variant. So Qt6Widgets_INCLUDE_DIRS will contain values for Widgets, Gui and Core. Qt6Widgets_LIBRARIES only contains a value like Qt6::Widgets, and when that is used in target_link_libraries(), CMake will take care of the transitivity. Change-Id: I625e25aab7ba5eaf14de1dc76ba2a1a0c85e6226 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-07-14 16:08:07 +00:00
list(REMOVE_DUPLICATES @QT_CMAKE_EXPORT_NAMESPACE@@target@_INCLUDE_DIRS)
list(REMOVE_DUPLICATES @QT_CMAKE_EXPORT_NAMESPACE@@target@_PRIVATE_INCLUDE_DIRS)
list(REMOVE_DUPLICATES @QT_CMAKE_EXPORT_NAMESPACE@@target@_DEFINITIONS)
list(REMOVE_DUPLICATES @QT_CMAKE_EXPORT_NAMESPACE@@target@_COMPILE_DEFINITIONS)
Write find_dependency() calls in Qt Module config files This change introduces a new function called qt_find_package() which can take an extra option called PROVIDED_TARGETS, which associates targets with the package that defines those targets. This is done by setting the INTERFACE_QT_PACKAGE_NAME and INTERFACE_QT_PACKAGE_VERSION properties on the imported targets. This information allows us to generate appropriate find_dependency() calls in a module's Config file for third party libraries. For example when an application links against QtCore, it should also link against zlib and atomic libraries. In order to do that, the library locations first have to be found by CMake. This is achieved by embedding find_dependency(ZLIB) and find_dependency(Atomic) in Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake. The latter is picked up when an application project contains find_package(Qt5Core), and thus all linking dependencies are resolved. The information 'which package provides which targets' is contained in the python json2cmake conversion script. The generated output of the script contains qt_find_package() calls that represent that information. The Qt5CoreDependencies.cmake file and which which dependencies it contains is generated at the QtPostProcess stop. Note that for non-static Qt builds, we only need to propagate public 3rd party libraries. For static builds, we need all third party libraries. In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any scope, the targets on which the property is set, have to be GLOBAL. Also for applications and other modules to find all required third party libraries, we have to install all our custom Find modules, and make sure they define INTERFACE IMPORTED libraries, and not just IMPORTED libraries. Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-24 15:14:25 +00:00
endif()
CMake: Add detection of FEATURE_foo change by user Unset all QT_FEATURE_foo values for every build. If any of FEATURE_foo is different of QT_FEATURE_foo, mark whole Qt build as dirty. Reset FEATURE_foo for dirty builds to the calculated value if it doesn't meet its condition. Set Qt module as NOT FOUND if its target was not created during configuration. Main issue with this approach are generated files, that became trash once the related features are disabled. This especially affects features that enable/disable Qt modules. FooConfig.cmake files are created and generate lots of warnings if feature was disabled. We may introduce a module cleanup procedure at some point. Fixes: QTBUG-85962 Pick-to: 6.0 Change-Id: Id71c1edb4027b24c6793063e40cc9d612c24ebce Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-12-11 15:11:35 +00:00
if (TARGET @QT_CMAKE_EXPORT_NAMESPACE@::@target@)
Add permission API backend for macOS and iOS When submitting applications to the iOS and macOS AppStore the application goes through static analysis, which will trigger on uses of various privacy protected APIs, unless the application has a corresponding usage description for the permission in the Info.plist file. This applies even if the application never requests the given permission, but just links to a Qt library that has the offending symbols or library dependencies. To ensure that the application does not have to add usage descriptions to their Info.plist for permissions they never plan to use we split up the various permission implementations into small static libraries that register with the Qt plugin mechanism as permission backends. We can then inspect the application's Info.plist at configure time and only add the relevant static permission libraries. Furthermore, since some permissions can be checked without any usage description, we allow the implementation to be split up into two separate translation units. By putting the request in its own translation unit we can selectively include it during linking by telling the linker to look for a special symbol. This is useful for libraries such as Qt Multimedia who would like to check the current permission status, but without needing to request any permission of its own. Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Change-Id: Ic2a43e1a0c45a91df6101020639f473ffd9454cc Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2022-05-10 13:02:43 +00:00
qt_make_features_available(@QT_CMAKE_EXPORT_NAMESPACE@::@target@)
CMake: Add detection of FEATURE_foo change by user Unset all QT_FEATURE_foo values for every build. If any of FEATURE_foo is different of QT_FEATURE_foo, mark whole Qt build as dirty. Reset FEATURE_foo for dirty builds to the calculated value if it doesn't meet its condition. Set Qt module as NOT FOUND if its target was not created during configuration. Main issue with this approach are generated files, that became trash once the related features are disabled. This especially affects features that enable/disable Qt modules. FooConfig.cmake files are created and generate lots of warnings if feature was disabled. We may introduce a module cleanup procedure at some point. Fixes: QTBUG-85962 Pick-to: 6.0 Change-Id: Id71c1edb4027b24c6793063e40cc9d612c24ebce Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-12-11 15:11:35 +00:00
foreach(extra_cmake_include @extra_cmake_includes@)
include("${CMAKE_CURRENT_LIST_DIR}/${extra_cmake_include}")
endforeach()
CMake: Store Qt features in CMake Cache This is less self-contained than what we have, but significantly speeds up cmake configure/generate runs. This patch also warns when a feature is already defined. Change-Id: I8cab63e208ba98756b47d362a39b462f5ec55e20 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-01-14 10:35:53 +00:00
CMake: Add detection of FEATURE_foo change by user Unset all QT_FEATURE_foo values for every build. If any of FEATURE_foo is different of QT_FEATURE_foo, mark whole Qt build as dirty. Reset FEATURE_foo for dirty builds to the calculated value if it doesn't meet its condition. Set Qt module as NOT FOUND if its target was not created during configuration. Main issue with this approach are generated files, that became trash once the related features are disabled. This especially affects features that enable/disable Qt modules. FooConfig.cmake files are created and generate lots of warnings if feature was disabled. We may introduce a module cleanup procedure at some point. Fixes: QTBUG-85962 Pick-to: 6.0 Change-Id: Id71c1edb4027b24c6793063e40cc9d612c24ebce Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-12-11 15:11:35 +00:00
if(EXISTS "${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@Plugins.cmake")
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@Plugins.cmake")
endif()
Collect more known modules when considering private libraries in extend_target. In extend_target(Foo) we go over all the ModulePrivate dependencies to assign them to FooPrivate. To do that we use the QT_KNOWN_MODULES variable. The problem is that the variable gets reset when we build a new repository, so when we build qtdeclarative, QT_KNOWN_MODULES has no entries for Core, Gui, etc, but only Qml, Quick, etc. And yet QmlPrivate has to depend on CorePrivate. Change the module Config.cmake files to append their target name to a global variable called QT_ALL_MODULES_FOUND_VIA_FIND_PACKAGE. The global variable gets populated every time find_package(QtFoo) is called. Use the union of QT_KNOWN_MODULES and QT_ALL_MODULES_FOUND_VIA_FIND_PACKAGE when considering FooPrivate libraries. Change-Id: Ibd9449744478cea58eb5d9737cc8887b4df92420 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-06-05 20:26:12 +00:00
CMake: Add detection of FEATURE_foo change by user Unset all QT_FEATURE_foo values for every build. If any of FEATURE_foo is different of QT_FEATURE_foo, mark whole Qt build as dirty. Reset FEATURE_foo for dirty builds to the calculated value if it doesn't meet its condition. Set Qt module as NOT FOUND if its target was not created during configuration. Main issue with this approach are generated files, that became trash once the related features are disabled. This especially affects features that enable/disable Qt modules. FooConfig.cmake files are created and generate lots of warnings if feature was disabled. We may introduce a module cleanup procedure at some point. Fixes: QTBUG-85962 Pick-to: 6.0 Change-Id: Id71c1edb4027b24c6793063e40cc9d612c24ebce Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-12-11 15:11:35 +00:00
list(APPEND QT_ALL_MODULES_FOUND_VIA_FIND_PACKAGE "@target@")
Match qt_import_plugin API with qt5's Some work was needed to make the plug-in types, and which plug-ins are available for each type in client code. Change-Id: Ib71feca31069deca3d3f54c8613054f5f8ae410c Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-23 14:57:06 +00:00
CMake: Add detection of FEATURE_foo change by user Unset all QT_FEATURE_foo values for every build. If any of FEATURE_foo is different of QT_FEATURE_foo, mark whole Qt build as dirty. Reset FEATURE_foo for dirty builds to the calculated value if it doesn't meet its condition. Set Qt module as NOT FOUND if its target was not created during configuration. Main issue with this approach are generated files, that became trash once the related features are disabled. This especially affects features that enable/disable Qt modules. FooConfig.cmake files are created and generate lots of warnings if feature was disabled. We may introduce a module cleanup procedure at some point. Fixes: QTBUG-85962 Pick-to: 6.0 Change-Id: Id71c1edb4027b24c6793063e40cc9d612c24ebce Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-12-11 15:11:35 +00:00
get_target_property(_qt_module_target_type "@INSTALL_CMAKE_NAMESPACE@::@target@" TYPE)
if(NOT _qt_module_target_type STREQUAL "INTERFACE_LIBRARY")
get_target_property(_qt_module_plugin_types
@INSTALL_CMAKE_NAMESPACE@::@target@ MODULE_PLUGIN_TYPES)
if(_qt_module_plugin_types)
list(APPEND QT_ALL_PLUGIN_TYPES_FOUND_VIA_FIND_PACKAGE "${_qt_module_plugin_types}")
endif()
Don't query MODULE_PLUGIN_TYPES property on interface libraries The reason is that interface libraries have to have properties prefixed with INTERFACE_ and more importantly we don't set the property for interface libraries at the moment. Amends d1542e8a73f535011d42970cc5b1b28a414c14c9. Change-Id: I86bf99995278b9086fa0e3815e10d5d54d9ea4dc Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
2019-11-04 10:26:22 +00:00
endif()
Generate metatypes dependency file Due to generator expression it is impossible to recursively evaluate the link dependencies of a target. This is required by QtDeclarative's qmltyperegistrar. To overcome this we generate a ${target}_metatypes_dep.txt file which contain lines with the following pattern: ${PATH_TO_METATYPES.json}=${PATH_TO_METATYPES_DEP.txt} This can be used to recursively evaluate the dependencies at run time. Change-Id: Ia4cee0632c16ba9631e0289db906fe9d320844a3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2020-01-27 13:56:40 +00:00
Load module specific extensions for QtBuildInternals This patch enables each module to load their own Qt${version}ModuleBuildInternals.cmake to expose module specific features when building Qt. These scripts are only loaded when the package QtBuildInternals has been loaded. Change-Id: Ie58dd93ddd292cf106fe7ef147151a51fd5aa2b1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-05 16:35:49 +00:00
CMake: Add detection of FEATURE_foo change by user Unset all QT_FEATURE_foo values for every build. If any of FEATURE_foo is different of QT_FEATURE_foo, mark whole Qt build as dirty. Reset FEATURE_foo for dirty builds to the calculated value if it doesn't meet its condition. Set Qt module as NOT FOUND if its target was not created during configuration. Main issue with this approach are generated files, that became trash once the related features are disabled. This especially affects features that enable/disable Qt modules. FooConfig.cmake files are created and generate lots of warnings if feature was disabled. We may introduce a module cleanup procedure at some point. Fixes: QTBUG-85962 Pick-to: 6.0 Change-Id: Id71c1edb4027b24c6793063e40cc9d612c24ebce Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-12-11 15:11:35 +00:00
# Load Module's BuildInternals should any exist
if (@INSTALL_CMAKE_NAMESPACE@BuildInternals_DIR AND
Load module specific extensions for QtBuildInternals This patch enables each module to load their own Qt${version}ModuleBuildInternals.cmake to expose module specific features when building Qt. These scripts are only loaded when the package QtBuildInternals has been loaded. Change-Id: Ie58dd93ddd292cf106fe7ef147151a51fd5aa2b1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-05 16:35:49 +00:00
EXISTS "${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@BuildInternals.cmake")
CMake: Add detection of FEATURE_foo change by user Unset all QT_FEATURE_foo values for every build. If any of FEATURE_foo is different of QT_FEATURE_foo, mark whole Qt build as dirty. Reset FEATURE_foo for dirty builds to the calculated value if it doesn't meet its condition. Set Qt module as NOT FOUND if its target was not created during configuration. Main issue with this approach are generated files, that became trash once the related features are disabled. This especially affects features that enable/disable Qt modules. FooConfig.cmake files are created and generate lots of warnings if feature was disabled. We may introduce a module cleanup procedure at some point. Fixes: QTBUG-85962 Pick-to: 6.0 Change-Id: Id71c1edb4027b24c6793063e40cc9d612c24ebce Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-12-11 15:11:35 +00:00
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@BuildInternals.cmake")
endif()
else()
CMake: Improve component / package not found error messages Provide better error messages when a Qt package / component is not found. Mention the location of the expected Config file on the file system, whether it exists Also mention the location of the Config file that was specified by the user when configuring the project or which CMake computed and stored in QtModule_DIR cache var. Mention that a package is not found in case if the main target exposed by that package is not found. If the target is not found, mention that it might be due to QT_NO_CREATE_TARGETS being set to TRUE (when it is set to true). If it is set to true, the assumption is that the target must have been defined by something else before the find_package call (either an earlier find_package call without QT_NO_CREATE_TARGETS set to TRUE or maybe it's the use case of Qt being built together with its examples or it's a super build). Unset _Qt_NOTFOUND_MESSAGE to ensure that the Qt6 not found error message is not spilled into any subsequent find_package(Qt6) calls, causing a cascade of unwarranted warnings / errors. Make sure to unset it only if components were specified, so the message is not shown or unset in any of the recursive find_package(Qt6) calls which is a dependency for regular Qt module packages. This works fine, because find_package(Qt6) calls with components are only done in project code and not done by the transitive dependency code (which looks for Qt6Foo packages directly). Remove some dead code. Pick-to: 6.2 Task-number: QTBUG-95532 Change-Id: Ie93d18e25e33aa0fe9e9da9a60e3d3e4cd6adb58 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-02 14:02:04 +00:00
set(@INSTALL_CMAKE_NAMESPACE@@target@_FOUND FALSE)
if(NOT DEFINED @INSTALL_CMAKE_NAMESPACE@@target@_NOT_FOUND_MESSAGE)
set(@INSTALL_CMAKE_NAMESPACE@@target@_NOT_FOUND_MESSAGE
CMake: Remove dead code It was accidentally left when changes were made from patchset 1 to patchset 2 in 825cb50c27fc0942a76771f9fb2ec052dc9142bf Amends 825cb50c27fc0942a76771f9fb2ec052dc9142bf Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I04dd50cfb93655f0c224bb226695e7771e9bc5d1 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-12 12:22:24 +00:00
"Target \"@QT_CMAKE_EXPORT_NAMESPACE@::@target@\" was not found.")
CMake: Improve component / package not found error messages Provide better error messages when a Qt package / component is not found. Mention the location of the expected Config file on the file system, whether it exists Also mention the location of the Config file that was specified by the user when configuring the project or which CMake computed and stored in QtModule_DIR cache var. Mention that a package is not found in case if the main target exposed by that package is not found. If the target is not found, mention that it might be due to QT_NO_CREATE_TARGETS being set to TRUE (when it is set to true). If it is set to true, the assumption is that the target must have been defined by something else before the find_package call (either an earlier find_package call without QT_NO_CREATE_TARGETS set to TRUE or maybe it's the use case of Qt being built together with its examples or it's a super build). Unset _Qt_NOTFOUND_MESSAGE to ensure that the Qt6 not found error message is not spilled into any subsequent find_package(Qt6) calls, causing a cascade of unwarranted warnings / errors. Make sure to unset it only if components were specified, so the message is not shown or unset in any of the recursive find_package(Qt6) calls which is a dependency for regular Qt module packages. This works fine, because find_package(Qt6) calls with components are only done in project code and not done by the transitive dependency code (which looks for Qt6Foo packages directly). Remove some dead code. Pick-to: 6.2 Task-number: QTBUG-95532 Change-Id: Ie93d18e25e33aa0fe9e9da9a60e3d3e4cd6adb58 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-02 14:02:04 +00:00
if(QT_NO_CREATE_TARGETS)
string(APPEND @INSTALL_CMAKE_NAMESPACE@@target@_NOT_FOUND_MESSAGE
"Possibly due to QT_NO_CREATE_TARGETS being set to TRUE and thus "
"${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@Targets.cmake was not "
"included to define the target.")
endif()
endif()
Load module specific extensions for QtBuildInternals This patch enables each module to load their own Qt${version}ModuleBuildInternals.cmake to expose module specific features when building Qt. These scripts are only loaded when the package QtBuildInternals has been loaded. Change-Id: Ie58dd93ddd292cf106fe7ef147151a51fd5aa2b1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-05 16:35:49 +00:00
endif()
Reference in New Issue Copy Permalink