[Development] Switch the main "Qt Build System"

[Alexandru Croitor]

> On 10. Jun 2020, at 04:39, André Pönitz <apoenitz at t-online.de> wrote:
> 
>> Here you can see the configurations that are rested currently in Coin.
>> 
>> https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/qtsvg.yaml (svg is
>> just an example)
>> 
>> So desktop Ubuntu, static qt builds on Suse, macOS framework builds (non-fw also
>> work), Windows MSVC2019, Windows MinGW 8, Android Arm64, iOS arm64.
> 
> I don't see any build there that looks like it might be a namespaced build.
> This has a high chance to not meet the "compiles" condition above for me.

That's right, there's no namespace build tested in the CI at the moment. 
I'll create a bug report so we try and add one.

> 
>> I'm waiting on some updates to switch iOS to simulator_and_device.
>> 
>> Android multi-ABI is currently not implemented, and we don't plan to do it for
>> 6.0.
> 
> Isn't Android support part of qtbase?

It is. Building Qt targeting Android with CMake works, but you only get one architecture (arm64 for example) in a single build tree, instead of more than one (arm64, armv7, x86, x64) like you used to when building with qmake. We will revisit the multi-arch approach later.

> 
>> We don't have WebAssembly at the moment, but it was tested to work at some
>> point.
>> 
>> Not shown here, we also have a Linux embedded arm qemu configuration in Coin for
>> qtbase, which will be expanded to other modules.
>> 
>>> Will it be possible to use bisect "all of Qt" with reasonable effort also for
>>> changes in the time until the transition is complete and the result is stable?
>>> E.g. will there be clear which state of which module compiles with which state
>>> of other modules with no or only short non-compilable phases inbetween?
>> 
>> If i understand correctly, this touches upon 2 topics.
>> 
>> 1) if we remove .pro files, there will be 3 periods of build systems. Before
>> 6.0, you'll have to configure and build with qmake, then a short period where
>> you can build with qmake and somewhat with cmake (depends on how far in the past
>> you go and at what state the cmake port was in that time), and post-removal of
>> .pro files, you'll only be able to build with cmake.
>> 
>> I don't think i can give you exact commit sets for that, so yes, it'll probably
>> be painful.
> 
> Given the amount of Qt5->6 code changes that would be an unfortunate situation.
> 
> Do you think it is really necessary to remove the .pro files at once? Wouldn't
> just not using them for your CMake file generation already be enough for you
> to proceed?

The desire is to get rid of the .pro files so we don't have to depend on the not-perfect-tool and not-perfect-situation that we have now.
The proposal was fast-tracked due to issues that people already have when they need to touch .pro files
I mentioned them in one of my replies to Alex (people don't use the tool, refuse to use the tool, don't want to touch the cmakelists.txt files, this leads to further integration issues for other people, etc).
> 
>> 2) dependencies.yaml
>> 
>> Which module compiles against which other module seems like a separate concern
>> that is not entirely related to the build system in all cases.
>> 
>> Figuring out combos of which module sha1s can be built together is already
>> somewhat of an issue with the current qmake build system, so that part is out of
>> scope for the CMake port team.
> 
> It was not about module sha1, but figuring out the way modules are build given
> a sha1. Effectively this would mean that at least in the early phases of a
> bisection one has to find out what setup has to used to build a module, too.

Yes. But how could we improve this really? Do we create some file in the root tree called "repo_does_not_build_with_qmake_anymore.txt"?

> 
>> Are you suggesting we somehow annotate the CMake part of the question? Like "we
>> guarantee you can build qtbase, qtdeclarative, qtquickcontrols2 with CMake with
>> SHAs X Y and Z? I'm not sure how useful that will be, given dev is constantly
>> moving forward.
> 
> I think part of the issue would be avoided if the .pro file were not purged
> until CMake is a full replacement.

"Full replacement" is a strong requirement which differs from person to person.
Of course it would be great if *everything* is done, and we flip a switch and everything works amazingly.

The reality is different though, and we need to switch at some point sooner rather than later.

The question becomes when, and what are the blockers for that, other than some inconvenience and an adaptation period.