[Development] Switch the main "Qt Build System"

[Alexandru Croitor]

> On 8. Jun 2020, at 18:47, Stottlemyer, Brett (B.S.) <bstottle at ford.com> wrote:
> 
> 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. 

The qtfoo.yaml files are used to declare the configuration (OS / compiler / arch) + configure flags. Those are used to configure qtbase, and build the rest of the dependencies, including your own module. The dependencies.yaml declares which sha1s of each repo to use. You can combine these to do whatever your module needs (extra configurations to test added or removed, specific sha1s).

> 
>    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 completely sympathise with the pain of porting. But we have to be pragmatic.

qmake mixing has been a goal for a long while, and we have spent an exorbitant amount of time on it, which in hindsight i think would have been better spent on the CMake port itself. 

We are fixing the known qmake mixing issues, and hopefully that can cover the usual cases. Unfortunately we can't spend more time on this due to limited time till Qt 6.0 release. 

Note that qmake mixing is not officially supported in the long run. qmake will support building applications and libraries, but not qt modules (qt_module.prf and friends). Otherwise we basically have to maintain two build system infrastructures (which we want to get away from).

Also note that developers were given time to port to CMake. And everyone that got stuck somewhere and needed help always received it (you are welcome at the #qt-cmake freenode channel).

I know Qt Creator currently has some quirks with the CMake workflow as well as the environment issues on macOS, but I can confirm that opening qtbase and friends is possible in Creator, albeit requiring some fiddling.

> 
> 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
>