[Development] Switch the main "Qt Build System"

[Alex Blasche]

> -----Original Message-----
> From: Alexandru Croitor <alexandru.croitor at qt.io>

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

This was referring directly to the line above it. How do I build a qmake module using CMake Qt? You mentioned the possibility and having done so with webengine but never provided details.
 
> > 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.

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. 


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

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


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

Please provide the details. How does one set such a build up?

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

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.

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

--
Alex