[Development] Switch the main "Qt Build System"

[Jean-Michaël Celerier]

Opening the root qt5/CMakeLists.txt has worked fine for me to work on e.g.
qt3d through QtCreator - did not really notice any performance penalty from
opening the whole project (except the initial "configure" step).

Kind regards,
Jean-Michaël
<http://www.jcelerier.name>


On Tue, Jun 9, 2020 at 10:05 AM Andy Nichols <Andy.Nichols at 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.
>
> Regards,
> 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.
>
> Thanks,
> Brett
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200609/5ab7b935/attachment-0001.html>