qt/qtdeclarative.git/src/quickcontrols2impl, branch wip/qtquickcontrols2 Qt Declarative (Quick 2) Remove unnecessary type registrtion function declarations 2021-07-16T22:33:15+00:00 Ulf Hermann ulf.hermann@qt.io 2021-07-16T10:58:44+00:00 fa5fc93958c77ece5d005b472c6220230cfc05fa For auto-generated plugins we don't need the declarations. Change-Id: I0250703e7c81debc6bc6ca526722c43b8a8058c8 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> (cherry picked from commit fd2a2808ac2c53220c907d7177aee0d172102859) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> 
For auto-generated plugins we don't need the declarations.

Change-Id: I0250703e7c81debc6bc6ca526722c43b8a8058c8
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
(cherry picked from commit fd2a2808ac2c53220c907d7177aee0d172102859)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
CMake: Don't give plugins PUBLIC usage requirements 2021-07-09T09:59:21+00:00 Joerg Bornemann joerg.bornemann@qt.io 2021-07-06T16:24:11+00:00 187c24b670fe6d19fb9780cac0945f2eba2d45c0 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. 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> (cherry picked from commit 9c30798a439e6a87b574472aca7a4e15107c6221) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> 
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.

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>
(cherry picked from commit 9c30798a439e6a87b574472aca7a4e15107c6221)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Update to latest qml CMake API 2021-06-05T10:52:00+00:00 Craig Scott craig.scott@qt.io 2021-05-31T06:40:54+00:00 5e8feb64d6a3cf50360c066e4595e41021bd0f9c 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> 
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 usage 2021-04-27T10:46:33+00:00 Maximilian Goldstein max.goldstein@qt.io 2021-04-27T08:55:37+00:00 f00d2fe304a1a48c48efb68e9a3ec6873c7ca355 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> 
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 version 2021-04-15T20:23:40+00:00 Alexandru Croitor alexandru.croitor@qt.io 2021-04-15T10:34:56+00:00 22e3b6d2292ded526354569a1ffb342a660f1f80 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> 
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>
Remove QMake project files 2021-02-11T15:43:37+00:00 Joerg Bornemann joerg.bornemann@qt.io 2021-02-09T16:07:49+00:00 be7c1c9dd4eeedf9760903b217de3d302bfe6c2c This includes removal of the corresponding .prev_CMakeLists.txt files. Pick-to: 6.1 Task-number: QTBUG-88742 Change-Id: I4247294258629c92e80914518e9208019090c815 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> 
This includes removal of the corresponding .prev_CMakeLists.txt files.

Pick-to: 6.1
Task-number: QTBUG-88742
Change-Id: I4247294258629c92e80914518e9208019090c815
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
CMake: Regenerate projects to use new qt_internal_ API 2020-10-07T19:54:30+00:00 Alexandru Croitor alexandru.croitor@qt.io 2020-09-23T09:34:07+00:00 ed65d1ab49e6f5537b086178f9f9d14fc190b663 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> 
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 build 2020-08-26T09:46:11+00:00 Mitch Curtis mitch.curtis@qt.io 2020-08-11T09:57:24+00:00 80c5d0841e6f7c0c9aedfdc01b5d060ab2f66b7d Task-number: QTBUG-82922 Change-Id: I75f4a553a6bb260f77bfa791f12fa42e80131e09 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> 
Task-number: QTBUG-82922
Change-Id: I75f4a553a6bb260f77bfa791f12fa42e80131e09
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Bump import version to 6.0 2020-08-26T09:46:08+00:00 Mitch Curtis mitch.curtis@qt.io 2020-07-15T12:52:09+00:00 9824a71f1d1754485072d66fbac2c98854ace52a Task-number: QTBUG-82922 Change-Id: I2eb924eaaaddbe75d342f59f5fb3cd30c4a84fef Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> 
Task-number: QTBUG-82922
Change-Id: I2eb924eaaaddbe75d342f59f5fb3cd30c4a84fef
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Register C++ types declaratively 2020-08-26T09:45:57+00:00 Mitch Curtis mitch.curtis@qt.io 2020-03-27T10:17:35+00:00 5246dd2de211ffb81313a5c29ae7894545a28c43 Adapt to the new way of registering C++ types. The types need to be seen at compile time so that code can be generated that invokes them. This patch: - Adds QML_* macros where applicable. - Adapts the build system files to the new way of registering modules. - Splits up the QtQuick.Controls[.*].impl files into their own plugins, as we can only register one QML module per .pro file. - Removes C++ type registration calls in every plugin. - Moves private types from src/quickcontrols2/quickcontrols2.pro to src/quickcontrols2/impl/quickcontrols2-impl.pro. Some of these types need to be exposed to QML, but quickcontrols2.pro is already in use to declare the QtQuick.Controls import (and also provides the public C++ QQuickStyle API), and the new QML_IMPORT_NAME/VERSION syntax only allows one module per project. As some of the types that need to be exposed to QML are also referenced by some C++ code (e.g. tests, etc.), we just move all of the private types to the new library. Follow-up patches will register the QML types declaratively. Task-number: QTBUG-82922 Change-Id: Iaf9ee106237d61701d57a8896f3822304c8151a6 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> 
Adapt to the new way of registering C++ types. The types need to be
seen at compile time so that code can be generated that invokes them.

This patch:

- Adds QML_* macros where applicable.
- Adapts the build system files to the new way of registering modules.
- Splits up the QtQuick.Controls[.*].impl files into their own plugins,
  as we can only register one QML module per .pro file.
- Removes C++ type registration calls in every plugin.
- Moves private types from src/quickcontrols2/quickcontrols2.pro
  to src/quickcontrols2/impl/quickcontrols2-impl.pro. Some of these
  types need to be exposed to QML, but quickcontrols2.pro is already in
  use to declare the QtQuick.Controls import (and also provides the
  public C++ QQuickStyle API), and the new QML_IMPORT_NAME/VERSION
  syntax only allows one module per project. As some of the types that
  need to be exposed to QML are also referenced by some C++ code (e.g.
  tests, etc.), we just move all of the private types to the new
  library.

Follow-up patches will register the QML types declaratively.

Task-number: QTBUG-82922
Change-Id: Iaf9ee106237d61701d57a8896f3822304c8151a6
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>