[Development] Switch the main "Qt Build System"

[Alexandru Croitor]

> On 9. Jun 2020, at 16:09, Alex Blasche <alexander.blasche at qt.io> wrote:
> 
> 
> Again this question was referring to the "build Qt module" with CMake Qt (aka your Webengine experiment). Not updating the dependencies is not desired at all. 

Sorry, I missed that the question was about qmake mixing.

You compile qtbase, qtdeclarative, etc with cmake as usual (qtbase/cmake/README.md), and then you call qt_prefix_install_path/bin/qmake on qtwebengine.pro && make && make install.

I've mentioned though, there are a few known issues tracked at https://bugreports.qt.io/browse/QTBUG-84781

> 
> 
>>> 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.
> 
> I am not blaming CMake port for the ignored status. I am pointing out a failure of your proposal only doing the non-ignored modules. A lot of ignored modules have a high update frequency which you leave in the lurch with your proposal. Right now this feels to me like releasing Joerg from his qmake duty and bully 60% of all modules into the corner. What you have enabled for CMake in CI will not deteriorate further. You had a trajectory going to convert the non-ignored modules converted. Why stop here and not continue? By 1.8. enabling cmake in CI could be done for 90% of the high turn over modules by the cmake experts, the module experts could continue on the task of updating against the myriads of other API changes. I bet with you that benefit outweighs the qmake maintenance effort.

The trajectory was always to port and enable in the CI, the modules that are not ignored in qt5.git.
There was no plan to port all modules in the qt/ namespace by the CMake Port team.

Is asking module owners to port to CMake really bullying? 

The fact that CMake configs do not deteriorate in the CI is not true.

While .pro files and qmake are the source of truth, people change the .pro / .pri / .prf file. They either forget or don't modify the cmake equivalents. Best-case the integration fails and they also do the cmake bits. 
Worst case the change integrates, and somewhere along the way another integration fails due to some combination of reasons that includes the fact that the previous change did not have the cmake bits.

The usual workflow is then to ask me or Joerg for help because that blocks all further integrations.

> 
> Using arguments like the python scripts pro2cmake.py is not effort. It doesn't count as argument

Not sure i understand this point.

>> 
>> 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.
> 
> Take one qmake config off and add an equivalent cmake conf. You swap one for one. There is no blow up. This is something you can do even today and you don't need to change any policy.

If we gradually replace qmake configs with cmake configs, then we lose qmake coverage, which means that people using qmake to build the modules will more likely start getting failures (especially in leaf modules), and this will again split the effort of fixing issues in 2 build systems.

> 
>>> - 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?
> 
> Let's put it this way. Those configurations verify that we can deliver a product with a certain quality. The key is swapping rather then duplicating targets. Swap 1for1 and we never create a test gap in the first place and the above question doesn't matter. Or what am I missing?

Personally I don't think swapping will help us, because we will be in an in-between state where we might have qmake and cmake failures in different places.

I do think we should have successful mirrored configurations in both qmake and cmake before we do a switch.