Skip to content
Snippets Groups Projects
Select Git revision
  • ulherman-master-patch-54841
  • master default protected
2 results
Blame Permalink
Forked from Alexandru Croitor / Qt6 CMake API Review
53 commits behind the upstream repository.
notes.md 3.02 KiB

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

  • 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.

  • Scope finalizer behavior
    • New CMake construct cmake_language(DEFER CALL) aka qmake's CONFIG += foo and foo.prf
    • Discussed the best way to leverage it in our API
    • Proposed approaches in 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.

  • 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
    • or on the gerrit changes

Gerrit review changes