First session discussion of general topics and Qml API

api_review_qt_6_2.md

@@ -18,15 +18,68 @@ General topics
     * warn if lower
     * limit min cmake requirement only on Linux and MinGW with a combination of the above two
 
+If CMake < 3.16 is used for user project, issue FATAL_ERROR. Allow opt-out, no support for that.
+
+Static build issues with object libraries.
+Approaches flowchart:
+CMake 3.21.0
+target_link_options >= 3.17 + policy
+target_link_libraries
+finalizer mode
+target_sources
+
+Require CMake 3.20 when using a static Qt, issue FATAL_ERROR, allow opt out like above with a cmake option, not support for that.
+Re-evaluate raising to requirement to 3.21.0 as soon as it is released, before Qt 6.2.0 release.
+Remove the finalizer mode API for object libraries, cause we require 3.20.
+The requirements are for both user projects and Qt build.
+The 3.21 bumping should happen only before qt 6.2.0 RC.
+We should update CI cmake to 3.20.0.
+
 
 QML topics extracted from notes taken in internal wiki page
 
 * figure out if we want to offer a convenience API for copying / installing QML files and non-qml resources on disk to the build and install dir (yes, we do!)
+
+We need the locations of qmldir, .qmltypes, the .qml files, the plugin.so and the resources (pngs, other image files, text documents).
+Provide a function to allow getting the locations of these things, so users can use install(TARGET) + install(FILES).
+Would be nice for 6.2, but it's kinda too late. Create a task for that.
+For this API, we should keep it TechnicalPreview.
+Users can copy-paste the implementation into their own user project and rename it, if the Qt they use don't have it yet.
+
 * Discussion about a default qml prefix and offering installation helpers for it
+$prefix/qml
+Concluded not to do installation of files as part of qt_add_qml_module. Users should use the API proposed above just to get the locations of files, and install them themselves.
+${QT6_HOST_PREFIX} + ${QT6_HOST_INFO_QMLDIR}
+
+
 * Possibly rename QT_RESOURCE_PREFIX property to QT_QML_MODULE_RESOURCE_PREFIX
+We don't want resources to be added to the qml import resource prefix via qt6_add_resources, only via qt_add_qml_module.
+Concluded to rename the property and recheck assumptions that we have with the internal usage of qt_add_resources.
+
 * Offer a qt_get_qml_module_resource_prefix public API, to get the PREFIX so that non-qml files can be passed into qt_internal_add_resource
+We probably don't need this in the public API anymore, because qt_add_qml_module was modified to take a RESOURCES option, so non-qml files are passed to
+qt_internal_add_resource as well.
+
+
 * Should typeinfo plugins.qmltypes be written to the qmldir file if there's no plugins.qmltypes file installed? Currently we always write it
+ This should be fixed, if there's no .qmltypes, don't write that entry into qmldir.
+
+
 * There are certain repos that specify a custom PLUGIN_TARGET with the previously added plugin name, instead of using the automatically generated name. Is there a good reason to keep those?
+At least for the Qt build itself, we don't need to set the PLUGIN_TARGET names, the auto-generated name should be ok.
+The advantage of removing, is the code won't be cargo culted into other projects.
+The advantage of keeping, is user projects can see the explicit target name for deployment purposes, but that's a bit far-fetched.
+
+Just a proposal
+```cmake
+qt_add_qml_module(Qml
+   # When not specified, the default target name will be QmlPlugin, so backing lib name + Plugin suffix
+   PLUGIN_TARGET QmlPlugin,
+   # The output name of the plugin when not specified should be lower case target name + snake case _plugin suffix.
+   FICTIONAL_PLUGIN_OUTPUT_NAME qml_plugin -> # libqml_plugin.so
+```
+
+We should bike-shed another day, because there wasn't consensus.
 
 # Meeting Notes
 
@@ -360,6 +413,51 @@ function(qt6_target_idl target)
 
 `qt6_add_qml_module` - existing TP API
 
+existing app + add_qml_module -> doesn't create plugin
+existing lib + add_qml_module -> creates plugin target by default
+non-existing app + add_qml_module -> doesn't create plugin
+non-existing lib + add_qml_module -> creates plugin target by default
+
+non-existing lib + add_qml_module + NO_CREATE_PLUGIN_TARGET -> doesn't create plugin target
+existing lib + add_qml_module + NO_CREATE_PLUGIN_TARGET -> doesn't create plugin target
+
+Naming.
+
+target_link_libraries()
+target_sources()
+qt_add_executable
+qt_add_qml_module
+
+qt_target_qml_module
+qt_target_attach_qml_module
+qt_target_qml_module
+
+qt_qml_module
+qt6_qml_module
+
+Consensus: Keep the name `qt6_add_qml_module`. MAKE SURE TO DOCUMENT IT CAN TAKE AN EXISTING TARGET.
+
+
+Discussion about the behavior of target creation by default.
+
+qt_add_qml_module calls qt_internal_add_plugin by default.
+qt_add_qml_module + NO_CREATE_PLUGIN_TARGET means -> won't call qt_add_qml_plugin. User project will do it.
+You still need to specify PLUGIN_TARGET, even though the project will create it later.
+
+
+```
+cmake
+# both work
+qt_add_qml_plugin(FooPlugin)
+qt_add_qml_module(Foo NO_CREATE_PLUGIN_TARGET PLUGIN_TARGET FooPlugin)
+
+qt_add_qml_module(Foo NO_CREATE_PLUGIN_TARGET PLUGIN_TARGET FooPlugin)
+qt_add_qml_plugin(FooPlugin)
+```
+
+A bit unclear on the consensus of the behavior, we should think about it one more time and re-discuss it
+at next time.
+
 `qt_add_qml_module`
 
 ```cmake