[Development] Switch the main "Qt Build System"

[Alexandru Croitor]

Hi,

Replying inline.

> On 8. Jun 2020, at 17:53, Stottlemyer, Brett (B.S.) <bstottle at ford.com> wrote:
> 
> Hi Alexandru,
> 
> On 6/8/20, 9:45 AM, "Development on behalf of Alexandru Croitor" <development-bounces at qt-project.org on behalf of alexandru.croitor at qt.io> wrote:
> 
>    The CMake ports are built in Coin with the most important configurations (Linux, Windows, macOS, Android, iOS, qemu Linux).
> 
> Are the "official" cmake configs for CI in the qt5 git repo yet (https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs)?  It would be nice to be able to mimic those to the extent possible.

Depends on how you define official. 

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

They are not in qt5.yaml (so the qt5.git product), because there's a Coin issue we are waiting to be fixed.

In most cases we try to mimic the qmake Packaging configurations.

If qtremoteobjects wants a CI tested cmake configuration, it's enough to copy qtsvg.yaml, and rename it to qtremoteobjects.yaml.
You'll have to poke people to schedule test builds though (because we shouldn't merge such a configuration until we confirm it actually builds, otherwise it will block all further commits).

> 
> Also, it looked like there were (last I checked) a bunch of modules not ready for Qt6 (including my own QtRemoteObjects).  What will this mean for those that need to convert to cmake still?

There was an email on the development list about qt 6.0 module inclusion. https://wiki.qt.io/Checklist_for_Qt_6.0_inclusion

If there's no cmake port ready, most likely the module will not be included for Qt 6.0.

Currently all repos that are not marked with status = ignore in qt5.git/.gitmodules have a cmake port, and are thus included.

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

> 
> Lastly, what are the best sources of help/hints for the conversion?

https://wiki.qt.io/CMake_Port/Porting_Guide
https://github.com/alcroito/qt6_cmake_port_slides/blob/master/QtCmakePort_ContributorSummit2019.pdf
https://code.qt.io/cgit/qt/qtbase.git/tree/cmake/README.md

Some of it might be a bit outdated though.

> 
> Regards,
> Brett
>