Add summary notes

README.md

+# Meeting notes and decisions
+
+See [notes.md](notes.md)
+
 # Discussion topics
 
 * Naming of `add_qt_gui_executable`

finalizers0.cmake

 # Approach 1: Straightforward
 
-cmake_minimum_required(VERSION 3.18)
-project(proj LANGUAGES CXX)
+# $ cat Qt6QmlConfig.cmake
 
 function(qt_add_qml_module target)
     add_executable(${target})
@@ -24,6 +23,11 @@ function(qt_run_qml_compiler target)
     # ... process
 endfunction()
 
+# $ cat CMakeLists.txt
+
+cmake_minimum_required(VERSION 3.18)
+project(proj LANGUAGES CXX)
+
 find_package(Qt6Qml)
 
 qt_add_qml_module(Foo)
@@ -46,8 +50,8 @@ qt_run_qml_compiler(target)
 
 find_package(Qt6Qml)
 
-add_library(Foo)
-target_link_libraries
+qt_add_qml_module(Foo)
+target_link_libraries(Foo INTERFACE Qt6::Qml)
 
 
 # $ cat Qt6Config.cmake
@@ -56,9 +60,13 @@ function(qt_add_qml_module target)
     add_executable(${target}) # No finalizer
 endfunction()
 
-add_library(Qt6::Core IMPORTED)
-cmake_language(DEFER CALL DIRECTORY "${CMAKE_SOURCE_DIR}" qt_finalizer_magic) # run after processing ALL CMakeLists.txt
-# Perhaps only CMakeLists.txt under the scope of the current directory's find_package(Qt6Core) call.
+add_library(Qt6::Qml IMPORTED)
+# ....
+
+# runs `qt_finalizer_magic` after processing ALL CMakeLists.txt
+cmake_language(DEFER CALL DIRECTORY "${CMAKE_SOURCE_DIR}" qt_finalizer_magic)
+# Consider running setting the directory scope to "${CMAKE_CURRENT_SOURCE_DIR}" instead, aka
+# the scope of the current directory's find_package(Qt6Qml) call.
 
 # This function gets all targets below this directory
 function(get_all_targets _result _dir)
@@ -71,12 +79,15 @@ function(get_all_targets _result _dir)
 endfunction()
 
 
-# Iterate over all targets in all projects, and run magic qt code for any target linking against a Qt6:: lib.
+# Iterate over all targets in all projects, and run magic qt code for
+# any target linking against a Qt6:: lib.
 function(qt_finalizer_magic)
     get_all_targets(targets "${CMAKE_CURRENT_SOURCE_DIR}")
 
     foreach(target ${targets})
         get_target_property(libs ${target} LINK_LIBRARIES)
+        # More code missing to handle cases where Qt might be pulled in
+        # transitively via another target's usage requirements.
         foreach(lib ${libs})
             if(lib MATCHES "^Qt6::")
                 qt_finalize_target(${target})
@@ -92,18 +103,19 @@ function(qt_finalize_target target)
     # .... other finalizers
 endfunction()
 
+
 # Possible problems with approach 2
 # Doing finalization things outside of the directory scope where the target is defined can lead to problems.
 # * Automatic Qt linkage detection might not work in all cases
-# * add_custom_command doesn't work properly
+# * add_custom_command doesn't work properly when added in a scope different from the scope where the consuming target is defined.
 # * GENERATED files don't work properly
 #    * Might be fixed in 3.20 via https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5308
 #    * Can partially be worked around using set_source_files_properties() + DIRECTORY option
 # * other issues i'm not aware of yet
 # * no PoC implemented yet :(
-# * users already expect magic to happen with things like AUTOMOC and AUTORCC, so approach 2 is not entirely insane
+# * users already expect magic to happen with things like AUTOMOC and AUTORCC, so approach 2 is not entirely crazy
 # * no consensus on whether approach 1 or 2
-# * it should be possible to implement approach 1, and then prove that 2 works, and incrementally switch to that.
 # * consider implementing approach 2 and keeping it disabled by default, and allow global opt-in via variable
+# * it should be possible to implement approach 1, and then prove that 2 works, and incrementally switch to that.
 #
 # Conclusion go with approach 1 for now, and iterate to try and implement approach 2

notes.md

-# General notes
+# Meeting summary notes
+
+* Naming of `add_qt_gui_executable`
+    * Decisions:
+        * rename to `qt_add_executable()` (provide also `qt6_add_executable()`)
+        * don't link against Qt::Gui by default
+        * remove the default options of `WIN32_EXECUTABLE` /  `MACOSX_BUNDLE`,
+          users can explicitly set them via `set_target_properties`
+        * Remove calls of `qt6_generate_win32_rc_file` from `qt_add_executable`
+    * discussion about `CMAKE_ANDROID_GUI`, and whether we should use it, no action point
+    * discussion about providing a public `qt_add_library()`, no action point
+
+<br>
+
+* Naming of internal functions in public Macros files
+    * Current code is mixed, some code uses `_qt` some uses `_qt_internal`, some might not be prefixed
+    * Proposal: use `_qt_internal_foo()` aka an underscore followed by `qt_internal`
+    * Note: Non-public macros files (like QtBuild.cmake) continue to use `qt_internal`
+      (note the lack of the front underscore).
+    * Decision: Will rename to `_qt_internal`, easier to grep.
+
+<br>
+
+* Scope finalizer behavior
+   * New CMake construct `cmake_language(DEFER CALL)` aka qmake's `CONFIG += foo` and `foo.prf`
+       * https://cmake.org/cmake/help/git-master/command/cmake_language.html#defer
+       * https://bugreports.qt.io/browse/QTBUG-77377
+   * Discussed the best way to leverage it in our API
+   * Proposed approaches in [finalizers0.cmake](finalizers0.cmake)
+   * Approach `1`
+       * Pros:
+           * easiest to implement
+           * usage is straightforward
+           * no magic
+           * no known issues with it
+       * Cons:
+           * Not as nice UX as `qmake`'s `CONFIG += foo`
+           * Needs explicit opt-in
+   * Approach `2` (magic)
+       * Pros:
+           * nicer UX
+           * if works well, no explicit opt-in needed
+       * Cons:
+           * might not be easy to implement (detect Qt usage in targets)
+           * a bit too much magic
+           * possible issues with CMake
+   * Decisions:
+       * Implement approach `1` first
+       * Implement approach `2` to check it's feasibility.
+           * Can incrementally switch from `1` to `2` in future Qt versions if it works.
+
+<br>
+
+* Should new CMake Public APIs be declared Technical Preview for Qt 6.0?
+    * Reasoning: Most of the new public APIs are not tested at all
+    * Especially `qt_add_plugin()` and `qt_add_qml_module()`
+      are complex and thus might not work
+    * Decision:
+        * Mark new public CMake API as TP for Qt 6.0
+        * Can be done with `qdoc`'s `\preliminary` tag.
+
+* API review:
+    * Notes can be found either inline in [api.md](api.md)
+    * or on the gerrit changes
+
+## Gerrit review changes
+
+* qtbase
+    * https://codereview.qt-project.org/c/qt/qtbase/+/317353
+* qtdeclarative
+    * https://codereview.qt-project.org/c/qt/qtdeclarative/+/317354
+* qtshadertools
+    * https://codereview.qt-project.org/c/qt/qtshadertools/+/317356
+* qtquick3d
+    * https://codereview.qt-project.org/c/qt/qtquick3d/+/317355
+* qtremoteobjects
+    * https://codereview.qt-project.org/c/qt/qtremoteobjects/+/317358
\ No newline at end of file