AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
5ec937115b
qt5base-lts/cmake/QtPluginConfig.cmake.in

30 lines
1.1 KiB
CMake
Raw Normal View History

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 12:33:28 +00:00
include_guard(DIRECTORY)
CMake: Fix auto-linking of static plugins in standalone tests The change introduced in 98e8180e56322ce065e39cc1ef1d65b54caa8c25 fixes reconfiguration issues for repositories that provide plugins associated with modules from a different repository (QSvgPlugin -> QtGui -> qtbase). It does so by only loading the public Plugin CMake packages of dependent repositories. For executables / tests that are built as part of the current repository, plugins are linked via a different simplified mechanism in qt_add_internal_plugin and qt_internal_add_plugin in order to prevent exporting link cycles between plugins and Qt modules. This works for the majority of in-tree tests, but unfortunately breaks static standalone tests. For example in qtbase neither mechanism will link plugins to the standalone tests: - qtbase has no repo dependencies, so the first mechanism (loading of public plugin packages) is skipped because we assume we are merely reconfiguring the main build of qtbase and we don't want to accidentally create duplicate plugin targets - because a standalone test configuration does not call qt_internal_add_plugin, no association is done between qt plugin and module and thus all tests (qt_internal_add_test -> qt_internal_add_executable) don't get the simplified plugin linking Fix this by allowing loading of the public CMake plugin packages when doing standalone tests. It should be safe to do so because we don't build any plugins in this case, only tests. Amends 98e8180e56322ce065e39cc1ef1d65b54caa8c25 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I690a0366c73a24e7f49c65ed13cd70362c273d81 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-20 15:23:47 +00:00
if(DEFINED QT_REPO_DEPENDENCIES 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 19:43:25 +00: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()
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 14:03:15 +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: 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 14:03:15 +00:00
include(CMakeFindDependencyMacro)
get_filename_component(_import_prefix "${CMAKE_CURRENT_LIST_FILE}" PATH)
get_filename_component(_import_prefix "${_import_prefix}" REALPATH)
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
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 14:44:13 +00:00
if(EXISTS "${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@Dependencies.cmake")
include("${CMAKE_CURRENT_LIST_DIR}/@INSTALL_CMAKE_NAMESPACE@@target@Dependencies.cmake")
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()
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 14:03:15 +00:00
Fix static builds after revamp of add_qt_resource The first issue is that instead of arg_OUTPUT_TARGET we should use rcc_OUTPUT_TARGET (there was also a typo in the OUTPUT word). The second issue came with the fact that the object library targets that were created for resources had a "Qt6::" namespace prefix in the exported Targets files, and yet the link generator expression did not contain the prefix. This failed when building qtsvg in a static build, because the exported object library could not be found. The solution is to use the TARGET_NAME generator expression which takes care of adjusting the name of the target when exported, thus making the linking work both when building qtbase and when building qtsvg. This had the fallout, that all resource object libraries need to be associated with an export set and installed. This wasn't the case for plugins, because plugins have an export name of the form "FooTargets", whereas the export name for the resource object library is "Qt6FooTargets". Adjust the export names of plugins to be the same as for modules and resource library objects (aka contain the "Qt6 prefix"). Change-Id: I1ca28d20c51e4447e5783cc20571a68ec77f6513 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-08-29 15:57:04 +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")
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()
Reference in New Issue Copy Permalink