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.
Regards,
Andy Nichols
-----Original Message-----
From: Development <development-boun...@qt-project.org> On Behalf Of
Stottlemyer, Brett (B.S.)
Sent: Monday, June 8, 2020 6:48 PM
To: Alexandru Croitor <alexandru.croi...@qt.io>
Cc: Qt development mailing list <development@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.croi...@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.
Thanks,
Brett
_______________________________________________
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
