Thursday, June 21, 2018

Qt Contributor Summit 2018

About two weeks ago i attended Qt Contributor Summit 2018, i did so wearing my KDAB hat, but given that KDE software is based heavily on Qt I think I'll give a quick summary of the most important topic that was handled at the Summit: Qt 6

  • Qt 6 is planned for a November 2020 release
  • Qt 5 releases will continue with the current cadence as of now with 5.15 being the last release (and also LTS)
  • The work branch for Qt 6 will be branched soon after Qt 5.12
  • Qt 6 has to be easy to migrate from Qt 5
  • Qt 6 will use C++17
  • Everything to be removed in Qt 6 should be marked as deprecated in 5.15 (ideally sooner)
  • What can be done in Qt 5 should be done to Qt 5
  • Qt 6 should be a "boring" release user feature wise, mostly cleanup and preparing for the future
  • Qt 6 should change things that break at compile time, those are easy to fix, silent runtime changes are scarier
  • Qt 6 will not use qmake as build system
  • The build system for Qt 6 is still not decided, but there's people working on a qbs build and noone working on any other alternative

On a community related note, Tero Kojo the Community Manager for The Qt Company is leaving and doesn't seem a replacement is on sight

Of course, note that these are all plans, and as such they may be outdated already since the last 10 days :D

11 comments:

  1. Any reason why Qt isnt moving to CMake (which appears to be a defacto standard now).

    ReplyDelete
  2. Qt can't use CMAke because CMake don't support all platforms Qt supports. Mobile, embedded, etc.

    ReplyDelete
  3. @ChochiseCesar What are you talking about? CMake is probably the easiest way to set up cross-compilation for whatever system you have as long as the rootfs and build tools (compiler, linker etc.) are present for that target system. I guess you have actually never worked with CMake to begin with.

    ReplyDelete
  4. Not to mention that CMake could... be extended to work with the platforms they want to target?

    It's not like no ones ever written a build system before... I heard that QBS thing fell out of the sky fully formed, ya kno?

    ReplyDelete
  5. "The build system for Qt 6 is still not decided, but there's people working on a qbs build and noone working on any other alternative"

    False. a port for CMake was reviewed and discarded for some reason nobody outside of the qt project seems to understand why.

    And Qt6 would need to ship the CMake files as well for the buildsystem integration so I really don't understand why they really wanna do double work.

    ReplyDelete
  6. KDE has switched to CMake quite a while now. Having Qt using CMake would make it easier to use with KDE developers. Having the same build system eases the work for everybody.

    Copperspice forked Qt (4) and now has (aloso) a CMake build option. Have a look at how it was done there ;)

    What would happen when C++ will have modules, every build system will have to support them. Why not just get that for free?

    ReplyDelete
  7. @Tomaz well, now may be a good time to push for that port again if you feel like it seems the message at the summit was quite clear cmake was [no longer] ruled out

    ReplyDelete
  8. Qbs is much easier to understand, for example its files are much clearer than the ones from CMake.

    ReplyDelete
  9. To work with CMake, and its complex (and sometimes not logical) rules, I have to see a lot of documents :-(

    ReplyDelete
  10. I have to see a lot of documents every time I work with CMake, I meant :-(

    ReplyDelete