[Development] Switch the main "Qt Build System"

Andy Nichols Andy.Nichols at qt.io
Tue Jun 9 09:59:05 CEST 2020

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.

Andy Nichols

-----Original Message-----
From: Development <development-bounces at qt-project.org> On Behalf Of Stottlemyer, Brett (B.S.)
Sent: Monday, June 8, 2020 6:48 PM
To: Alexandru Croitor <alexandru.croitor at qt.io>
Cc: Qt development mailing list <development at qt-project.org>
Subject: Re: [Development] Switch the main "Qt Build System"

Hi Alexandru,

Thanks for the quick reply.

´╗┐On 6/8/20, 12:09 PM, "Alexandru Croitor" <alexandru.croitor at qt.io> wrote:

    The current CMake configurations can be found in qt5.git/coin/platform_configs/qtsvg.yaml (and many other .yaml files there, it's just copy-pasted). 

Ahh, I didn't understand what these module specific versions were for.  I guess you download the dependencies (like qtbase) with the expected sha and same config, rather than building again?  That makes sense. 
    There was an email on the development list about qt 6.0 module inclusion. https://clicktime.symantec.com/3Y88fCHSqah7h6p9gH8GzbV7Vc?u=https%3A%2F%2Fwiki.qt.io%2FChecklist_for_Qt_6.0_inclusion

Yes, I'm aware.  That's where I see a lot of modules with no response or NOT READY as the status.
    If the module is not included (no cmake port), you can start using the dependencies.yaml mechanism to pin which sha1s of qtbase, declarative, etc to use, and continue building against those sha1s with qmake. Of course once the .pro files in qtbase are gone, you will be stuck to the last set of SHA1s that still have the .pro files. See dependencies.yaml in qtquickcontrols2.git for example.
    We have a qmake mixing mechanism (build qtremoteobjects with qmake against a qtbase built with CMake), but it's not 100% ready yet (the known issues are being fixed), and thus modules could continue to build with qmake against even newer sha1s, but I wouldn't bet too much on this approach (we tried our best to make it work, but there are bound to be corner cases even after we fix the known issues).
I'll suggest "qmake mixing" be a prerequisite to flipping the switch to cmake.  It is hard enough to port to Qt6 with the binary incompatibilities.  If you make the build system side of this too painful as well, you risk modules not being carried to Qt6.  I know it is a different topic, but I am unable to open a developer build of qtbase (from cmake) in QtCreator - it wants to configure the project again (not to mention trying to get Ninja in the path for QtC on mac).  This all makes it hard to be an "early adopter", but doing the work later means you have to tackle all of these issues at once.  Without CI, presumably, after this change (at least for modules).

I'm not arguing against the change, just want you guys to keep in mind what this is like for those of us that haven't been developing in Qt6 from the start.


Development mailing list
Development at qt-project.org

More information about the Development mailing list