[Development] Switch the main "Qt Build System"

[Alexandru Croitor]

> On 9. Jun 2020, at 13:56, Alex Blasche <alexander.blasche at qt.io> wrote:
> 
> 
> Could you share details how this is done?

Which part?
First we'd have to remove all qmake configs in qt5.git/coin/platform_configs, leaving just the cmake ones.
Once that's integrated, we can push & stage changes that remove .pro files.


> Can I assume that existing CI targets for those not activated cmake modules continue to work (despite continuing dependencies.yaml updates)?

If a module does not have a cmake port, the safe option is to use dependency sha1s that still have the .pro files, which means you can't update dependencies.yaml past that point. 

You can try updating dependencies.yaml past the removal point and thus try using the qmake mixing, but as I've mentioned in a previous reply
I can't guarantee that it will work for all modules in all configurations.

The best way is to port the module to CMake.

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

Just as a clarification, the ignored modules in .gitmodules are ignored initially not due to CMake, but to ease qt5.git integrations because of the fast turnover in qtbase and qtdeclarative. It would be unfair to pin that on the CMake port.

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

I never have enough bandwidth. 

That being said, I still try to help the maintainers with the ports and activating them in the CI (see for example qtopcua, qt3d and qtmqtt).

I believe I also provided feedback for one of the modules that you were trying to enable in the CI.

Also note that merging the wip/cmake branches to dev is fine from my point of view. The problem is enabling it in the blocking CI, because if the port doesn't work, you're blocking any further integrations. There's also the minor issue that people might see the cmakelists.txt and think that means the port is done, but that's minor in the grand scheme of things.

See my previous replies regarding qmake mixing (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.

I guess my best answer is: over time, yes. 

I'm slowly doing that for iOS and qemu, but it's a very slow process because i need to wait for qtbase integrations (where my fixes usually are) to propagate to other repos, or all the way to qt5.

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

We didn't want to blow up Coin integration times, so we didn't include so far every possible configuration.
Building examples and developer build activation is a simple change. For debug-and-release we are waiting for the CMake 3.18 official release.

> - Linux QEMU  (completely dropped from auto testing)

That's on the to do list to enable.

> - WebAssembly completely lost

That is true. As I mentioned in my reply to Andre, we tested it at some point, but we don't have current plans to add it to the CI.

> - not a single namespace or libinfix build left (afaict)

That's also true, and would have to be investigated.

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

That is also true. But I'll ask one more time. How long do we wait? When everything is perfectly ready? What if that takes too long and doesn't fit in the 6.0 release schedule or feature freeze or platform freeze, or any other randomly chosen milestone period?