Discussion topics

• Naming of add_qt_gui_executable

  • rename to qt_add_executable(foo)
  • don't link against Qt::Gui by default
  • remove the default options of WIN32_EXECUTABLE / MACOSX_BUNDLE, users can add it
  • discussion about CMAKE_ANDROID_GUI, and whether we should use it
  • discussion about providing a public qt_add_library()
  • investigate if we should remove qt6_generate_win32_rc_file from qt_add_executable
  • offer also a qt6_add_executable variant.
  • Conclusion: see above

• API review

• Naming of internal functions in public Macros files

  • Current code is mixed, some uses _qt some uses _qt_internal, some might not be prefixed
  • Proposal: use _qt_internal_foo() aka an underscore followed by qt_internal
  • Conclusion: It's okay to rename to _qt_internal, easier to grep

• Scope finalizer behavior

  • cmake_language(DEFER CALL) aka qmake's CONFIG += foo and foo.prf
  • Best way to leverage it for our API
  • Should we consider using find_package(Qt) magic to call finalizers
  • https://cmake.org/cmake/help/git-master/command/cmake_language.html#defer
  • https://bugreports.qt.io/browse/QTBUG-77377
  • Conclusion: see final comments in finalizers0.cmake

• Should new CMake Public APIs be declared Technical Preview for Qt 6.0?

  • (Spoiler - Alexandru thinks yes)
  • 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 (due to not being tested)
  • Conclusion: it's okay to mark new public CMake API as TP for Qt 6.0

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