<div dir="ltr"><div>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).</div><div><br></div><div>Kind regards,</div><div>Jean-Michaël<br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><font size="2" face="arial, helvetica, sans-serif" color="#134f5c"><a href="http://www.jcelerier.name" target="_blank"></a></font></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 9, 2020 at 10:05 AM Andy Nichols <<a href="mailto:Andy.Nichols@qt.io">Andy.Nichols@qt.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Alexandru,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards,<br>
Andy Nichols<br>
<br>
-----Original Message-----<br>
From: Development <<a href="mailto:development-bounces@qt-project.org" target="_blank">development-bounces@qt-project.org</a>> On Behalf Of Stottlemyer, Brett (B.S.)<br>
Sent: Monday, June 8, 2020 6:48 PM<br>
To: Alexandru Croitor <<a href="mailto:alexandru.croitor@qt.io" target="_blank">alexandru.croitor@qt.io</a>><br>
Cc: Qt development mailing list <<a href="mailto:development@qt-project.org" target="_blank">development@qt-project.org</a>><br>
Subject: Re: [Development] Switch the main "Qt Build System"<br>
<br>
Hi Alexandru,<br>
<br>
Thanks for the quick reply.<br>
<br>
On 6/8/20, 12:09 PM, "Alexandru Croitor" <<a href="mailto:alexandru.croitor@qt.io" target="_blank">alexandru.croitor@qt.io</a>> wrote:<br>
<br>
    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). <br>
<br>
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. <br>
<br>
    There was an email on the development list about qt 6.0 module inclusion. <a href="https://clicktime.symantec.com/3Y88fCHSqah7h6p9gH8GzbV7Vc?u=https%3A%2F%2Fwiki.qt.io%2FChecklist_for_Qt_6.0_inclusion" rel="noreferrer" target="_blank">https://clicktime.symantec.com/3Y88fCHSqah7h6p9gH8GzbV7Vc?u=https%3A%2F%2Fwiki.qt.io%2FChecklist_for_Qt_6.0_inclusion</a><br>
<br>
Yes, I'm aware.  That's where I see a lot of modules with no response or NOT READY as the status.<br>
<br>
    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.<br>
<br>
    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).<br>
<br>
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).<br>
<br>
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.<br>
<br>
Thanks,<br>
Brett<br>
<br>
_______________________________________________<br>
Development mailing list<br>
<a href="mailto:Development@qt-project.org" target="_blank">Development@qt-project.org</a><br>
<a href="https://lists.qt-project.org/listinfo/development" rel="noreferrer" target="_blank">https://lists.qt-project.org/listinfo/development</a><br>
_______________________________________________<br>
Development mailing list<br>
<a href="mailto:Development@qt-project.org" target="_blank">Development@qt-project.org</a><br>
<a href="https://lists.qt-project.org/listinfo/development" rel="noreferrer" target="_blank">https://lists.qt-project.org/listinfo/development</a><br>
</blockquote></div>