summaryrefslogtreecommitdiffstats
path: root/cmake/QtPluginConfig.cmake.in
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Fix build of Release user projects against RelWithDebInfo QtJoerg Bornemann2020-09-251-0/+1
| | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Prepare ground work for static Qml plugins importingAlexandru Croitor2020-08-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Implement qtbase fixes for superbuildsJean-Michaël Celerier2020-01-081-0/+2
| | | | | | Change-Id: I0d3445cf0740e3925fa9342dac4d07892518afe5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Fix static builds after revamp of add_qt_resourceAlexandru Croitor2019-08-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Allow to build examples as standalone projectKevin Funk2019-06-051-5/+7
| | | | | | | | | | | | | | | | 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>
* cmake: register plug-ins, create dependencies fileJean-Michaël Celerier2019-06-041-0/+13
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>