First round of 6.8 api review

api_review_qt_6_8.md

@@ -30,8 +30,23 @@ Has "since qt version" blurb.
 
 **Notes:**
 
-**Action points:**
+```cmake
+# current signature
+qt_wrap_cpp("" myapp.cpp TARGET myapp)
+
+# new proposed signature
+qt_wrap_cpp(TARGET myapp myapp.cpp)
+```
 
+**Action points:**
+AP: Rewrite the docs for new signature to be a list instead of a paragraph
+    (or at least make it more readable)
+AP: Look if we can implement the new signature
+AP: Adjust the new signature snippet in the docs
+AP: Should probably be two different signatures in the docs
+AP: Recommend the new signature instead, more user friendly
+AP: Investigate if we can show a warning when using old signature, or find a way
+    to accomodate the distinction between TARGET foo signature and first param ${target} signature
 
 
 
@@ -44,6 +59,8 @@ New implementation is used by default starting with Qt 6.8.
 https://codereview.qt-project.org/c/qt/qtbase/+/513648 - CMake: Set AUTOGEN_BETTER_GRAPH_MULTI_CONFIG
 
 https://doc-snapshots.qt.io/qt6-dev/cmake-standard-property-autogen-better-graph-multi-config.html
+https://cmake.org/cmake/help/latest/prop_tgt/AUTOGEN_BETTER_GRAPH_MULTI_CONFIG.html
+https://cmake.org/cmake/help/latest/variable/CMAKE_AUTOGEN_BETTER_GRAPH_MULTI_CONFIG.html#variable:CMAKE_AUTOGEN_BETTER_GRAPH_MULTI_CONFIG
 
 Signature
 
@@ -58,6 +75,10 @@ Has "since qt version" blurb.
 **Notes:**
 
 **Action points:**
+AP: Add an example snippet to set the property, also for the `CMAKE_AUTOGEN_BETTER_GRAPH_MULTI_CONFIG` variable
+AP: Mention also the cmake variable in the qt docs of the target property
+
+
 
 
 
@@ -71,7 +92,7 @@ https://codereview.qt-project.org/c/qt/qtbase/+/542757 - CMake: Bring back renam
 **Notes:**
 
 **Action points:**
-
+AP: Remove the leftover code
 
 
 
@@ -100,6 +121,15 @@ Not TP.
 **Notes:**
 
 **Action points:**
+AP: Add doc backlinks from designer documentation to that command and anywhere else we mention `.ui` files.
+AP: Make `qt_wrap_ui` and `AUTOUIC` as links in the docs at the bottom of the `When to prefer` section, and remove links
+    from the qt_add_ui, becase we are already on the page
+
+
+more doc pages:
+https://doc.qt.io/qt-6/cmake-get-started.html
+https://doc.qt.io/qt-6/designer-using-custom-widgets.html
+
 
 
 
@@ -110,6 +140,7 @@ New build target to build an android `aar` file instead of an `apk` or `aab`.
 
 https://codereview.qt-project.org/c/qt/qtbase/+/551535 - Android: Add facilities to build AAR packages
 https://codereview.qt-project.org/c/qt/qtdoc/+/563436 - docs
+https://codereview.qt-project.org/c/qt/qtbase/+/563192 - test
 
 https://doc-snapshots.qt.io/qt6-dev/android-building-projects-from-commandline.html#building-an-aar-android-archive-file
 
@@ -127,7 +158,15 @@ Not TP.
 
 **Notes:**
 
+Discussion about whether the aar should be triggered by qt_add_executable or qt_add_library
+One possibility is to consider postponing to 6.9, and add as new feature for qt_add_library,
+and some optin/out flag for qt_add_executable
+
 **Action points:**
+AP: Add links in docs to the upstream android documentation for AAR (and probably AAB, APK)
+AP: Add a since Qt 6.8 blurb to docs, perhaps also for aab
+AP: Investigate the real difference of apk vs aar, and which of the entry point commands should be used
+    qt_add_executable or qt_add_library
 
 
 
@@ -150,6 +189,10 @@ IS TP.
 **Notes:**
 
 **Action points:**
+AP: Un-TP it
+AP: Add an example snippet to the docs
+
+
 
 
 
@@ -170,10 +213,18 @@ IS TP.
 
 **Notes:**
 
+This is currently a project based approach, and not a target based-approach.
 
 **Action points:**
 
 AP: Missing backlink to `QT_QML_GENERATE_JAVA_CLASS`.
+AP: Add a doc note that enabling this variable makes sense only for AAR packages
+AP: Fabian: Does it makes sense that is is project-based approach instead of target?
+AP: Clarify in the docs that it is a boolean
+AP: Add a doc link to whatever `QtQmlComponent` is
+AP: Add example snippet to doc
+AP: The name 'QtQmlComponent' will be changed to something, so have to adjust the docs here too
+AP: Keep it TP for now, and confirm after we talk with customers who need this and PMs (sync with Mr. Bruno)
 
 
 
@@ -200,8 +251,10 @@ IS TP.
 
 
 **Action points:**
-
-
+AP: Add doc snippet how to use
+AP: Keep TP, talk to relevant people
+AP: Rename `QT_QML_GENERATE_JAVA_CLASS` to `QT_QML_GENERATE_ANDROID_JAVA_CLASS`, and consider adding the non-android name
+    some time later after QmlNext materialises
 
 
 
@@ -226,6 +279,10 @@ Not TP.
 **Notes:**
 
 **Action points:**
+AP: Fix examples to use new policy
+AP: Fix or silence policy warnings in qtdeclarative modules like `quickdialogsquickimpl`
+AP: Add a example snippet to the docs
+AP: Fabian: Explain a bit more when you would want to use this, and the benefit, especially for examples, into the policy docs
 
 
 
@@ -249,7 +306,10 @@ Not TP.
 **Notes:**
 
 **Action points:**
-
+AP: Add example snippets to docs
+AP: Mention `DEPENDENCIES, IMPORTS, OPTIONAL_IMPORTS and DEFAULT_IMPORTS`
+    in doc of qt_add_qml_module, currently some of them are missing
+AP: Fabian: Document limitation on transitive dependencies, or fix it
 
 
 
@@ -274,6 +334,10 @@ What is behavior for < 3.19? Appears to be no-op without a warning?
 Does introducing an opt-out make sense?
 
 **Action points:**
+AP: Check if we can support older cmake versions, or if we should issue a warning
+AP: Double check that the qt.conf is only created if the QTP0005 policy is NEW
+AP: Add documentation somewhere
+AP: Add an opt out option, to not generated the qt.conf in case of some conflict
 
 
 
@@ -309,6 +373,11 @@ Same for the counterpart `qt_generate_wayland_protocol_server_sources`, patch pe
 **Notes:**
 
 **Action points:**
+AP: Add since qt version
+AP: Add example snippet
+AP: Add missing link to doc page
+AP: Ask maintainers if it makes sense to introduce a new cmake policy to swap the default to use `PRIVATE_CODE`
+
 
 
 
@@ -347,9 +416,11 @@ Should it link to grpc docs as well?
 **Notes:**
 
 **Action points:**
-
-
-
+AP: Update doc string for `EXTRA_NAMESPACE`
+AP: Re-arrange snippets and recheck regarding QML_URI whether it is required
+AP: Check if `QML_URI` issues warning if target already exists, rephrase as appropriate
+AP: Mention the .proto file names beforehand in the `Resolving dependencies between protobuf targets` doc section
+AP: Consider simplifying / rephrasing the PUBLIC link blue not in the same section