[Development] Switch the main "Qt Build System"

[Alex Blasche]

> -----Original Message-----
> From: Development <development-bounces at qt-project.org> On Behalf Of
> Alexandru Croitor
 
> -----------------------------> TL;DR here <----------------------------------------
> 
> The CMake Port team wants to switch the main Qt build system to the CMake
> one.
> 
> What this means:
> 
> - All Coin qmake configurations in dev branch are removed.
> 
> - Only CMake configurations are built in Coin.
> 
> - CMakeLists.txt files are now the source of truth (no more editing of .pro / .pri
> files).
> 
> - All qmake .pro / .pri files of ported repositories under Coin control are
> removed.
> 
> - No more pro2cmake.py and configurejson2cmake.py usage (except for an
> initial port of a yet un-ported repository)
> 
> - You need CMake to build Qt.
> 
> - Un-ported repositories should still be able to build with qmake against a CMake
> built Qt (this was tested to work for qtwebengine, but not other repositories,
> there are a few known issues left that we're currently fixing).

Could you share details how this is done? Can I assume that existing CI targets for those not activated cmake modules continue to work (despite continuing dependencies.yaml updates)?

About 30 out of 50 modules where set to ignore in gitmodules. About half of those 30 modules get very regular updates at the very least to push their dependencies.yaml forward. Often those cases involve porting to new qtbase changes. 
A lot of those modules have a cmake port in a side branch. When asked about this a few weeks ago why we shouldn't merge them to dev you stated that you don't have the bandwidth to help people activating them in the CI. Do you suddenly have the bandwidth to help all those module maintainers to port them to cmake or even enable the qmake against CMake Qt? 

 
> --> Proposed time of execution: 1st of July <--
> 
> 
> I'd like to hear about any Qt development blockers that you foresee due to this
> change.

Will you create test/configuration parity in the CI? Currently the CMake configurations don't even cover all the config options we support via qmake. This creates a big long term problem. For example:

- there is only on mac build one cmake -> 3 qmake (drops debug-and-release, drops building examples, no developer build)
- Linux QEMU  (completely dropped from auto testing)
- WebAssembly completely lost
- not a single namespace or libinfix build left (afaict)
- various other configurations are missing too

Unless we can at least convert a couple more CI configurations to cmake it sounds to me we want to save effort on the build system side against a big black box of unknown/not tested problems we won't even notice.