aboutsummaryrefslogtreecommitdiffstats
path: root/src/quickcontrols2impl/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* Remove qtquickcontrols2 sources and explain where they wentHEADdevMitch Curtis2021-08-161-43/+0
| | | | | | | | | | | | Now that qtquickcontrols2 has been merged into qtdeclarative, we should make it obvious that this repo should no longer be used, by preventing it from being built. Task-number: QTBUG-95173 Pick-to: 6.2 Change-Id: I95bd6a214f3d75a865ab163ee0a1f9ffbeb7a051 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* CMake: Don't give plugins PUBLIC usage requirementsJoerg Bornemann2021-07-091-4/+0
| | | | | | | | | | | | | | | | | | | | | | | The pro2cmake.py conversion script faithfully reproduced the .pro files for the plugins, which specified the libraries as public. But in CMake, the implications of this are that public usage requirements should then be propagated to consumers. We don't expect any consumers, since a plugin is created as a MODULE library in CMake, so for Windows we don't even have an import library to link with. The only exception to this is for static builds where plugins are created as STATIC libraries instead, but only in certain controlled situations do we then link to plugins. Even then, usage requirements are not expected to propagate to the consumers, so these relationships should always be specified as private. As a drive-by fix, remove Qt::Foo dependencies that are already implied by Qt::FooPrivate. Pick-to: 6.2 Task-number: QTBUG-90819 Change-Id: I3f33766612367520e09e599f03ac06d43613aa81 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Update to latest qml CMake APICraig Scott2021-06-051-23/+7
| | | | | | | | | | | | | | The new qml CMake API places a closer relationship between the backing target and the plugin target. Both are typically created together and they share a lot of common details. Instead of creating them in different parts of the source tree, they are now specified together. The src/imports area has effectively been absorbed into the other corresponding subdirectories below src with this change. Task-number: QTBUG-91621 Change-Id: I9bd32e9eb78c198ccc9db04e2829303cac323502 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Remove GENERATE_METATYPES usageMaximilian Goldstein2021-04-271-1/+0
| | | | | | | We now generate metatypes by default and every instance of GENERATE_METATYPES now causes a warning. Change-Id: I691d0a3973c47cab666bd4ca948b2afe047ee13f Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* CMake: Fix qml module version to use the repo project versionAlexandru Croitor2021-04-151-1/+1
| | | | | | | | | | | Use PROJECT_VERSION instead of CMAKE_PROJECT_VERSION, so that the repo project version is used in a top-level build, rather than the version of the qt5 project. Pick-to: 6.1 6.0 Task-number: QTBUG-92861 Change-Id: Ifd12d6309f358b9b72372a5c069141ecb7322bc7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Regenerate projects to use new qt_internal_ APIAlexandru Croitor2020-10-071-2/+2
| | | | | | | | Modify special case locations to use the new API as well. Task-number: QTBUG-86815 Change-Id: I4a690095fcd4b1141550de86b6820ae2dd579429 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Fix CMake buildMitch Curtis2020-08-261-0/+64
Task-number: QTBUG-82922 Change-Id: I75f4a553a6bb260f77bfa791f12fa42e80131e09 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>