Hi, "Putting that aside, how long should we wait then? " is exactly the question we would like to find the answer to __
My own preference is to make the switch to CMake as soon as possible and use effort to improving the CMake port instead of keeping the qmake as a parallel build system for Qt itself. Having the mixing support as an option is beneficial, and something we wanted to offer to the extent feasible without risking the overall Qt 6.0 development. We are currently at a point where all the most commonly used modules are built with CMake. There is a bit less than 3 months to Qt 6.0 feature freeze and around 8 months to Qt 6.1 feature freeze. This should be adequate time to make the changes in all the relevant modules. The goal is for all the Qt 6.0 modules are in place at the Structure and platform freeze milestone (end of June, https://wiki.qt.io/Qt_6.0_Release). This allows us to have things ready well before the feature freeze - and avoid situations where some larger changes are done close to the FF deadline, potentially causing instability. We should not accept any modules that are still built with qmake to the Qt 6.0 release content. So, let's continue the discussion and aim to reach the conclusion in the next few days for the best path forward related to the topic. Yours, Tuukka On 9.6.2020, 11.45, "Development on behalf of Alexandru Croitor" <development-boun...@qt-project.org on behalf of alexandru.croi...@qt.io> wrote: Hi Andy, I'll acknowledge that the current Qt Creator <-> Build Qt with CMake situation is sub-par. Though, I believe there is a sketchy config to allow you to use a released Qt Creator to develop Qt. Putting that aside, how long should we wait then? I'm not sure if we can afford to delay the switch for much longer, for many reasons: - I don't know how long it would take to improve Creator to do "the right thing". - The Qt releasing team needs to start creating and testing packages based on the CMake-built Qt - Developers are burdened with maintaining 2 build systems (not just the CMake port team, but also other developers doing regular Qt6.0 work) We have to bite the bullet at some point. > On 9. Jun 2020, at 09:59, Andy Nichols <andy.nich...@qt.io> wrote: > > Hi Alexandru, > > I think Brett touches on the biggest blocker for me and that is actually related to Qt Creators ability to open and use modules built using cmake. I am actually really impressed with state of the CMake support for build Qt as it is right now, and wish I could more actively use it, but unfortunately my current workflow involves using Qt Creator to develop Qt, and I have to work on modules that are not just QtBase. Despite adding my cmake based Qt Builds to Creator as kits (which seems to only be possible using qmake), it isn't possible for Creator to easily recognize that my module's are built with that kit when loading them. I hear rumors that it is possible, but most of the guys who say that are only working on qtbase anyway. > > I think that before we kill the qmake based build of Qt, that our own IDE should support developing Qt itself. And I would be happy with some "sketchy config" that works with a released version of Qt Creator for now, but this shouldn't be good enough to justify killing qmake before a real solution is in place. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
