[Development] Switch the main "Qt Build System"

[Alexandru Croitor]

> On 9. Jun 2020, at 04:32, André Pönitz <apoenitz at t-online.de> wrote:
> 
> On Mon, Jun 08, 2020 at 01:43:20PM +0000, Alexandru Croitor wrote:
>> [...]
>> The CMake ports are built in Coin with the most important configurations
>> (Linux, Windows, macOS, Android, iOS, qemu Linux).
> 
> Is there a list of configurations that work/do not work?

I'm not sure what your definition of works is.

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

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.

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.

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.