[Development] Switch the main "Qt Build System"

[Marius Kittler]

Hi,

Am Dienstag, 9. Juni 2020, 12:07:02 CEST schrieb Bogdan Vatra via Development:
> I'm using qmake for Qt6 when I'm doing Android work, also for this reason.
> I don't want to build Qt twice just to use a "cool and superior" build system.
>
> Just out of curiosity, can some pretty please remind me what are the
> advantages of using cmake to build Qt over qmake?
> I'm not talking about Qt users, for them we should support all (major) build
> systems: qmake, cmake, meson, etc.

It seems we have quite different use-cases and workflows because I actually 
understood that as a useful change - especially the part that Qt no longer 
weirdly builds for two target (host and actual target) in one go, see my 
comment here:
https://aur.archlinux.org/packages/mingw-w64-qt5-base/#pinned-750114

Additionally:

When building only for one target at a time it is always clear to which target 
compiler flags, linker flags, dependency lookups and so on apply. That removes 
a lot of complexity from the build system.

So far I'm building qmake, bootstrapping libraries and other tools for i686-
w64-mingw32, x86_64-w64-mingw32, x86_64-linux-android, arm-linux-androideabi 
and aarch64-linux-android and in the future maybe for even more targets. In Qt 
6 I will be able to save built time on all of these targets by simply making 
use of the host version of Qt. That sounds like a clear win since the host 
version of Qt should be available on all platforms I possibly want to build 
for these targets.

The multi-ABI build for Android looks more like a hack to workaround having to 
build host tools multiple times. It comes with the disadvantage of making the 
build process more complex. Features which work for other targets like using 
system provided libraries instead of the bundled ones are likely problematic 
due to that. At the same time it is limited to Android and not a generic 
feature. If the goal is to make one Android package which contains binaries 
built for different targets: Why not simply let androiddeployqt pick up these 
binaries from different builds? Just allow one to pass multiple install 
directories/prefixes for these libraries at a time. That sounds way simpler 
and would also work for other dependencies a project might have besides Qt.

Best Regards
Marius