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 <[email protected]> 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 <[email protected]> On Behalf Of > Stottlemyer, Brett (B.S.) > Sent: Monday, June 8, 2020 6:48 PM > To: Alexandru Croitor <[email protected]> > Cc: Qt development mailing list <[email protected]> > 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" <[email protected]> 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 > [email protected] > https://lists.qt-project.org/listinfo/development > _______________________________________________ > Development mailing list > [email protected] > https://lists.qt-project.org/listinfo/development >
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
