QtCS2021 - Qt Buildsystem Feedback: Difference between revisions
Jump to navigation
Jump to search
m (Volker Hilsheimer moved page Qt Buildsystem Feedback to QtCS2021 - Qt Buildsystem Feedback) |
No edit summary |
||
Line 10: | Line 10: | ||
==Notes== | ==Notes== | ||
(Notes by alcroito) | |||
=== Status update === | |||
* 99% of platforms and repositories ported | |||
* Various improvements to CMake upstream | |||
* New public CMake API for qml modules in 6.2 | |||
* New public CMake API plugin, executable, translation creation | |||
* Still things to work on like unified deployment story, android multi-ABI, better docs | |||
=== Feedback session === | |||
* Some positive feedback | |||
* Some pain points still exist | |||
* IDE integration can be improved (don't reconfigure, don't rebuild, don't clobber files when not needed) | |||
* Sanitizer flags should propagate to applications like in qmake https://bugreports.qt.io/browse/QTBUG-92083 | |||
* Discussed if any issues can arise as part of qtquickcontrols2 -> qtdeclarative merge (qmlimportscanner issues in tests mostly) | |||
* Request to add a new feature for a documentation toggle of CMake vs qmake code | |||
* Request to document that one can build a test without having to build all of Qt | |||
* Request to document how to get the command line that is used to run a specific test or test function | |||
* qmake was easier to use for standard projects, but extremely hard for non-standard projects | |||
* Positive feedback on providing a unified deployment story (non-official linuxdeployqt is a pain point) https://bugreports.qt.io/browse/QTBUG-74940 | |||
* No longer being able to open a Qt library and/or tests as self-contained projects in Qt Creator slows down development | |||
** At least test projects can be made standalone, needs some manual work https://bugreports.qt.io/browse/QTCREATORBUG-25389 | |||
** Possibly distribute the work via @dev mailing list | |||
* Question about if CMake allows to bundled macos / ios related data as qmake allowed to, can be done using https://cmake.org/cmake/help/latest/prop_tgt/MACOSX_BUNDLE_INFO_PLIST.html | |||
* Documentation needs to be updated in many places to also include the cmake way of doing things: like in this post where it only shows the qmake addition but no cmake: https://doc-snapshots.qt.io/qt6-dev/qtqml-cppintegration-topic.html | |||
** This is being worked on as part of new QML CMake API documentation | |||
* Request to add support for sanitizers when using MSVC | |||
* Platform plugins are not built by default when building a test (this should be fixed though?) | |||
* There seems to be a bit a dependency creep; some small changes in some obscure file seem to trigger a full rebuild of qtbase, this also propagates to Qt for Python | |||
** Needs thorough investigation | |||
* Pointed out that CMake help can be received at https://discourse.cmake.org/ | |||
=== Poll === | |||
* 65% ish - Prefer cmake + ninja | |||
* 5% ish - Prefer qmake + make | |||
* 10% ish - Both are fine | |||
* 1% - I wanted to choose something else | |||
* Some people didn't answer |
Revision as of 12:54, 23 June 2021
Session Summary
- Qt 6 switched to using CMake for building Qt. The session is meant to gather feedback / pain points about building Qt as well as using Qt in a user project (from a build system perspective). General questions about build system usage are also welcome.
Session Owners
- Alexandru Croitor (alexandru.croitor@qt.io)
Notes
(Notes by alcroito)
Status update
- 99% of platforms and repositories ported
- Various improvements to CMake upstream
- New public CMake API for qml modules in 6.2
- New public CMake API plugin, executable, translation creation
- Still things to work on like unified deployment story, android multi-ABI, better docs
Feedback session
- Some positive feedback
- Some pain points still exist
- IDE integration can be improved (don't reconfigure, don't rebuild, don't clobber files when not needed)
- Sanitizer flags should propagate to applications like in qmake https://bugreports.qt.io/browse/QTBUG-92083
- Discussed if any issues can arise as part of qtquickcontrols2 -> qtdeclarative merge (qmlimportscanner issues in tests mostly)
- Request to add a new feature for a documentation toggle of CMake vs qmake code
- Request to document that one can build a test without having to build all of Qt
- Request to document how to get the command line that is used to run a specific test or test function
- qmake was easier to use for standard projects, but extremely hard for non-standard projects
- Positive feedback on providing a unified deployment story (non-official linuxdeployqt is a pain point) https://bugreports.qt.io/browse/QTBUG-74940
- No longer being able to open a Qt library and/or tests as self-contained projects in Qt Creator slows down development
- At least test projects can be made standalone, needs some manual work https://bugreports.qt.io/browse/QTCREATORBUG-25389
- Possibly distribute the work via @dev mailing list
- Question about if CMake allows to bundled macos / ios related data as qmake allowed to, can be done using https://cmake.org/cmake/help/latest/prop_tgt/MACOSX_BUNDLE_INFO_PLIST.html
- Documentation needs to be updated in many places to also include the cmake way of doing things: like in this post where it only shows the qmake addition but no cmake: https://doc-snapshots.qt.io/qt6-dev/qtqml-cppintegration-topic.html
- This is being worked on as part of new QML CMake API documentation
- Request to add support for sanitizers when using MSVC
- Platform plugins are not built by default when building a test (this should be fixed though?)
- There seems to be a bit a dependency creep; some small changes in some obscure file seem to trigger a full rebuild of qtbase, this also propagates to Qt for Python
- Needs thorough investigation
- Pointed out that CMake help can be received at https://discourse.cmake.org/
Poll
* 65% ish - Prefer cmake + ninja * 5% ish - Prefer qmake + make * 10% ish - Both are fine * 1% - I wanted to choose something else * Some people didn't answer