summaryrefslogtreecommitdiffstats
path: root/cmake/QtPlugins.cmake.in
Commit message (Collapse)AuthorAgeFilesLines
* Avoid cyclic dependency between plugin and module *Config.cmake filesCraig Scott2021-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | In static per-repo builds, we have a mix of targets provided by packages and targets provided by the main build. For the builds that create the packages, we must avoid adding a dependency for the main module library target on its associated plugin targets or else the package config files end up with a cyclic dependency that cannot be resolved when something tries to consume them. This only happens for static builds because we have been attaching a linking relationship to the main module library that isn't really a true dependency, we attached it only for convenience of things linking to that module library. To preserve that convenience linking without breaking the config packages, we use the QT_NO_CREATE_TARGETS condition to prevent CMake seeing that relationship when generating the *Config.cmake files. Creating these relationships will be delayed until the plugin's *Config.cmake file is loaded, at which point it will add itself to the main module library's imported target INTERFACE (this was already done before, we just now rely solely on that). Task-number: QTBUG-90819 Pick-to: 6.1 Change-Id: Id725742182bcda64841be84fe1650bafb9151bb1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Fix static top-level buildJoerg Bornemann2021-01-221-7/+7
| | | | | | | | | | | | | | Commit d0071a4f871 broke static top-level builds: CMake Error at .../qtbase/lib/cmake/Qt6Gui/Qt6GuiPlugins.cmake:17 (set_property): set_property can not be used on an ALIAS target. Fixed by moving the un-aliasing of the target before the set_property call. Pick-to: 6.0 Change-Id: I96c731353798a58ff9b3a664f3614ef03c897dcb Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Only generate and add static plugin imports once per module targetCraig Scott2021-01-211-2/+18
| | | | | | | | | | | | | | | | | | | Projects may call find_package(Qt6 ...) multiple times. When enabling examples and tests, this happens a lot. For a statically built Qt, for modules that have plugins (e.g. Gui), every time the module's config file was loaded, it was generating and adding another copy of the import plugin sources to the module target. These accumulated and created many duplicates, which in turn blew out generation time and made the build very inefficient. This change checks whether the import plugin sources have already been processed for the module target and ensures they are only added once. It records its status on the target itself so that both local and global targets are supported. Fixes: QTBUG-90465 Change-Id: I1f45b1ee771a933ee755d44f1e983d6d9113dad0 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Do not export the QT_PLUGINS target property of Qt modulesJoerg Bornemann2021-01-201-2/+1
| | | | | | | | | | | This property is dynamically determined and set in the Qt6${module-name}PluginsConfig.cmake files now. There is no need anymore to export this property. Change-Id: I2d164864c4099034b88f9ad852eae8b9f9e55f8b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Fix loading of Qt6*Plugin.cmake files of per-repo buildsJoerg Bornemann2021-01-201-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When doing a per-repository build of Qt, as it is done for the installer packages, the build of qtbase has no knowledge of plugins that might be built and installed from other repositories. That means we must not write a fixed list of known plugins when exporting Qt modules of qtbase. In particular, qtsvg adds imageformat plugins that are supposed to be picked up by qtbase's QtGui module when linking a project against a statically linked Qt. ${install-prefix}/lib/cmake/Qt6Gui/Qt6GuiPlugins.cmake missed the include statements for qtsvg's plugin config files and operated on a fixed list of plugins, all from qtbase. Apart from that, the Qt6::Gui target's property QT_PLUGINS did only contain the qtbase plugins. This patch fixes the situation in the following way: 1. All Qt6*PluginConfig.cmake files in ${install-prefix}/lib/cmake/Qt6Gui are detected and included. 2. From those file names, the target names of the plugins are deduced. This is safe as the file name of those generated files is a direct result of the plugin's target name. 3. The QT_PLUGINS property of the module is updated with the detected plugin target names. Fixes: QTBUG-89643 Change-Id: Ifc3c39aa9948277ead5ebb209ec5eff64746308b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix prl files of static Qt buildsAlexandru Croitor2020-08-061-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Static Qt plugins should not be included in the list of libraries of a prl file. They end up being there due to our circular dependency trick where the plugins depend on the module they belong to. This in turn causes the giant static plugin generator expressions to be processed in qt_collect_libs(), and the generated prl file ends up having target names like Qt6::QJpegPlugin which are obviously not linker flags. To eliminate the static plugins from prl files, add an additional dummy boolean generator expression '$<BOOL:QT_IS_PLUGIN_GENEX>' that always evaluates to true. We can string match on this expression in qt_collect_libs, and thus remove the whole static plugin genex entry. This should fix linking of apps with qmake that use a CMake-built static Qt. Task-number: QTBUG-85865 Task-number: QTBUG-85240 Task-number: QTBUG-85801 Change-Id: I949dc5edb10d94c4ab84ed430af7c164d8efaaa6 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Fix qt_import_plugins compatibility with Qt 5Alexandru Croitor2020-01-271-1/+18
| | | | | | | | | | Handle versionless plugin names passed to qt_import_plugins. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: Ic7fb6e54d2822c7eb58a7874b4a1c137f0c101d9 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Fix Generator Expression for static non-prefix buildsLeander Beernaert2020-01-101-1/+1
| | | | | Change-Id: Icd32164943d7bb0639de3022bae749d0010674fc Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Implement qtbase fixes for superbuildsJean-Michaël Celerier2020-01-081-7/+24
| | | | | | Change-Id: I0d3445cf0740e3925fa9342dac4d07892518afe5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Fix automatic plugin importing in static buildsAlexandru Croitor2019-10-091-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | QtPlugins.cmake.in uses file(GENERATE) and target_sources() to propagate the generated cpp files which contain plugin initialization code to their consuming targets. Unfortunately due to a bug in CMake, if the file is generated in a different scope than the consuming target, the CMake generation step will fail saying that the source file can not be found. See https://gitlab.kitware.com/cmake/cmake/issues/18399 for details. In the case of qtdeclarative, find_package(Qt6) is called at the top level scope (this is when the file gets generated), but the targets are created in subdirectory scopes, and the GENERATED source file property is not propagated across scropes. Circumvent the issue by instead using file(WRITE) and configure_file() which create the file at configure time rather than generate time. This will pollute the current binary directory with some more files, but at least successfully fixes the build. Change-Id: I3ab3b12dcbf6a9d0ab9ee87173e4a1952325b37b Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
* Match qt_import_plugin API with qt5'sJean-Michaël Celerier2019-10-091-10/+49
| | | | | | | | | | 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
* Fix building examples when doing a Qt static buildAlexandru Croitor2019-07-221-1/+11
| | | | | | | | | | | | | | | | | | The build failed due to two different reasons. We tried to assign properties on an aliased target, which does not work. Make sure to set properties on the original unaliased target. We tried to query for the value of the QT_DEFAULT_PLUGINS property when automatically linking to plugins, but the generator expression failed in the AND section, because querying for an unexisting value does not return an integer, and the AND expression expects an integer. The fix is to wrap the relevant expression in a BOOL generator expression. Change-Id: Ia065bc1de939cee49e5de0b2aef70e356cc5419a Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
* cmake: implement default qpa plugin behavior for static buildsJean-Michaël Celerier2019-07-051-8/+8
| | | | | | | | | | | | | | | | | This is done by adding a DEFAULT_IF argument to add_qt_plugin, which accepts if-evaluated expressions. e.g. add_qt_plugin(myplugin DEFAULT_IF ${foo} STREQUAL ${bar} ... ) so that this mechanism can be reused later if necessary. Change-Id: I7eba9adaaa28e55a4f0f94cf206e868b990027e6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: allow client apps to load static plug-insJean-Michaël Celerier2019-07-051-0/+40
Based in part on Kyle Edwards's implementation : https://codereview.qt-project.org/c/qt/qtbase/+/243731 Example : ``` cmake_minimum_required(VERSION 3.15) project(foo) add_executable(foo main.cpp) find_package(ICU COMPONENTS i18n uc data REQUIRED) find_package(Qt6 COMPONENTS Core Gui REQUIRED) target_link_libraries(foo Qt6::Core Qt6::Gui) qt_import_plugins(foo INCLUDE Qt6::qxcb EXCLUDE Qt6::qgtk3 Qt6::qeglfs-kms-integration Qt6::qjpeg ) ``` Change-Id: If7736c42f669f7d7f43052cae59c28fc7fcb4156 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>