diff --git a/README.md b/README.md index ee3c8ff8660f215cf46455c6d1d3a3970c8c3566..bdf5062d1d3a638e2bc205e9d1c04950f4ed75cf 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,7 @@ +# Meeting notes and decisions + +See [notes.md](notes.md) + # Discussion topics * Naming of `add_qt_gui_executable` diff --git a/finalizers0.cmake b/finalizers0.cmake index e558579f1002fb8602845e77b4270b80afcfdb8b..1b9263dda5d6043a16bdfda43385c681f385e7f6 100644 --- a/finalizers0.cmake +++ b/finalizers0.cmake @@ -1,7 +1,6 @@ # 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 diff --git a/notes.md b/notes.md index fe9aba678cab6ca77cb862d2fe2013c96f699dfa..bc3f90572102c49543d80f955043df227a7f123d 100644 --- a/notes.md +++ b/notes.md @@ -1 +1,77 @@ -# 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