[Development] Switch the main "Qt Build System"

[André Pönitz]

On Tue, Jun 09, 2020 at 08:06:57AM +0000, Alexandru Croitor wrote:
> > 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.

My definition of "works" in this context is "Doesn't get in my way,
i.e. compiles, and doesn't crash for the things I am using".

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

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

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

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

Andre'