> On 9. Jun 2020, at 16:09, Alex Blasche <[email protected]> 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. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
