1berry/qtbase
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
qtbase/cmake/QtPluginConfig.cmake.in

38 lines
1.2 KiB
CMake
Raw Permalink Normal View History

Change license for .in files According to QUIP-18 [1], all build system files should be BSD-3-Clause. The files in this patch are part of the build system. [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: Ibc6a60a9b009fab0c953e8e3269533c121e4511e Reviewed-by: Kai Köhne <kai.koehne@qt.io>
2024-02-20 09:45:50 +01:00
# Copyright (C) 2024 The Qt Company Ltd.
# SPDX-License-Identifier: BSD-3-Clause
Implement qtbase fixes for superbuilds Change-Id: I0d3445cf0740e3925fa9342dac4d07892518afe5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2019-11-21 13:33:28 +01:00
include_guard(DIRECTORY)
CMake: Fix linking of qtsvg static plugins in standalone tests build Our QtPluginConfig.cmake.in files have code to skip loading plugins unless the repo is found in the QT_REPO_DEPENDENCIES variable or when building standalone parts. The problem is that QT_INTERNAL_BUILD_STANDALONE_PARTS is only assigned a value after all the find_package calls have executed, which is too late for the qtsvg standalone tests, because the svg icon config file would already be loaded and skipped. This code path checked for QT_BUILD_STANDALONE_TESTS, before the introduction of the QT_INTERNAL_BUILD_STANDALONE_PARTS variable. QT_BUILD_STANDALONE_TESTS is set by the qt-internal-configure-tests script, so it is always available. Restore the previous check for QT_BUILD_STANDALONE_TESTS, while keeping the new variable as well. This fixes the tst_qicon_svg test to pass in a static standalone tests build. Amends 62905163bf887c2c2c9ba7edcd64c96d237a6e95 Restores behavior of be1ee03a0fafa28efa0c0e45f21f9dc684625957 Pick-to: 6.8 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I19f620a39fe530bf7f96498cfad1c90621983eb6 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Toni Saario <toni.saario@qt.io>
2024-10-21 11:32:41 +02:00
if(DEFINED QT_REPO_DEPENDENCIES
AND NOT QT_INTERNAL_BUILD_STANDALONE_PARTS
AND NOT QT_BUILD_STANDALONE_TESTS)
Fix error when re-configuring an already installed Qt repository When building and installing a Qt repo that provides plugins for a Qt module within a different repository (for example, qtimageformats providing imageformat plugins for QtGui), re-configuring that repository would result in configuration errors like "add_library cannot create ALIAS target "Qt6::QTgaPlugin" because another target with the same name already exists." This happened, because the find_package(Qt6 COMPONENTS Gui) calls pulled in the Qt6*PluginConfig.cmake files that create imported targets for the plugins we want to build. To fix this, when building Qt, we now load only plugins that are provided by repositories the currently building repository depends on. We read the repo dependencies from dependencies.yaml when the Qt6BuildInternals package is loaded, but only in static builds and only if we're currently building a Qt repository. To find out whether we're building a Qt repository, we check whether QT_REPO_MODULE_VERSION is defined. We cannot check QT_BUILDING_QT, because that variable is not available for the first find_package calls in the repository's top-level project file. In each Qt6*PluginConfig.cmake file, we bail out if the plugin's repository is not one of the ones in QT_REPO_DEPENDENCIES. Fixes: QTBUG-86670 Fixes: QTBUG-91887 Change-Id: I8f6c8398032227032742f1ca019e983ff2bcd745 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-22 20:43:25 +01:00
# We're building a Qt repository.
# Skip this plugin if it has not been provided by one of this repo's dependencies.
string(TOLOWER "@PROJECT_NAME@" lower_case_project_name)
if(NOT lower_case_project_name IN_LIST QT_REPO_DEPENDENCIES)
return()
endif()
endif()
Avoid creating the installed test plugins when configuring standalone tests When configuring standalone tests with some installable plugins, these plugins land inside the actual build/install directory after build/installation. This makes imposible to configure the same standalone tests second time since the same plugin targets attempt to be created within the build tree, while they are already found by the respective find_package(<Qt Module>) call. This change introduces and uses the tests-wide qt_internal_configuring_tests variable to mark the plugins that are built within the tests build tree and disallows loading them by the find_package call when building standalone tests. The trick is simple: PluginConfig.cmake files skip plugin creation if the respective plugin is a test plugin and the standalone test project matches the plugin repo project. Also we now oblige module maintainers to mark such plugins using the TEST_PLUGIN argument of the qt_internal_add_plugin function. This is needed to prevent breakage when the exact test is build alone and the qt_internal_configuring_tests is not set. If plugin is not marked as TEST_PLUGIN and is built as part of test build tree the warning is displayed to remind the maintainer about the missing flag. Suggest to make this flag mandatory for all test plugins, and throw a FATAL_ERROR if the plugin is not marked respectively. Fixes: QTBUG-127781 Change-Id: I51f8b2f2c979911dad7c90926d841c8b8f1bb5d7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-08-06 16:32:48 +02:00
@skip_internal_test_plugin@
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 16:03:15 +02: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 18:46:49 +11:00
cmake_minimum_required(VERSION @min_new_policy_version@...@max_new_policy_version@)
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 16:03:15 +02:00
include(CMakeFindDependencyMacro)
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 17:08:47 +02:00
if (NOT QT_NO_CREATE_TARGETS)
# Find required dependencies, if any.
CMake: Prepare ground work for static Qml plugins importing For qt_import_qml_plugins to work, it needs to have access to the Qml plugin targets by the time find_package(Qt6Qml) is called. To do that, we modify the generation of Qml plugin Config, Targets and Dependencies files to go into a special 'QmlPlugins' subfolder of the Qml package. The Qml package will then GLOB include all the Config files in that folder, to make them available whenever find_package(Qt6Qml) is called. This is similar to how the Qt plugins were glob included in the CMake integration of Qt 5.15. In fact that glob including is missing in Qt 6 for regular Qt plugins, and should be implemented in a following change. Currently the Qt Plugins config files that are included are hardcoded to the list of known plugins at Qt configuration time. As a drive-by to make this all work, the naming of the various Config and Dependencies files has been normalized to include the Qt6 prefix. This is done for both regular Qt plugins and Qml plugins. Task-number: QTBUG-85961 Change-Id: Id20da72337ca2945fa330ea6fb43535e44a83292 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-10 16:44:13 +02:00
if(EXISTS "${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@Dependencies.cmake")
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@Dependencies.cmake")
Avoid creating Plugin targets if the dependencies are missing The plugin lookup mechanism doesn't handle the situation, when the plugin is available but it's private dependency(static plugin case) is missing. In this case we currently silently bypass the dependency lookup and create targets. So users see the confusing message about missing linked target, like: Qt6QSQLiteDriverPluginTargets.cmake:61 (set_target_properties): The link interface of target "Qt6::QSQLiteDriverPlugin" contains: SQLite::SQLite3 but the target was not found. Possible reasons include: * There is a typo in the target name. * A find_package call is missing for an IMPORTED target. * An ALIAS target is missing. This indeed should be handled properly and we should omit creating targets especially if users don't really use the plugin directly. Also if dependencies are not satisfied it looks logically to set the <plugin>_FOUND to false as this will be yet another indicator for user that the plugin is not found. Task-number: QTBUG-132244 Pick-to: 6.8 6.9 6.5 Change-Id: I8685163df0dee3a728c724901f69780569ffcad5 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-12-17 18:41:32 +01:00
else()
set(@target@_FOUND TRUE)
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 17:08:47 +02:00
endif()
cmake: register plug-ins, create dependencies file This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 16:03:15 +02:00
Avoid creating Plugin targets if the dependencies are missing The plugin lookup mechanism doesn't handle the situation, when the plugin is available but it's private dependency(static plugin case) is missing. In this case we currently silently bypass the dependency lookup and create targets. So users see the confusing message about missing linked target, like: Qt6QSQLiteDriverPluginTargets.cmake:61 (set_target_properties): The link interface of target "Qt6::QSQLiteDriverPlugin" contains: SQLite::SQLite3 but the target was not found. Possible reasons include: * There is a typo in the target name. * A find_package call is missing for an IMPORTED target. * An ALIAS target is missing. This indeed should be handled properly and we should omit creating targets especially if users don't really use the plugin directly. Also if dependencies are not satisfied it looks logically to set the <plugin>_FOUND to false as this will be yet another indicator for user that the plugin is not found. Task-number: QTBUG-132244 Pick-to: 6.8 6.9 6.5 Change-Id: I8685163df0dee3a728c724901f69780569ffcad5 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-12-17 18:41:32 +01:00
if(@target@_FOUND)
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@Targets.cmake")
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@AdditionalTargetInfo.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 17:08:47 +02:00
endif()
Reference in New Issue Copy Permalink