Let's see how this will work out: https://www.qt.io/blog/aab-support-in-qt-for-android
For us it likely still makes most sense to keep the architectures distinct. This feature makes not much sense if only Qt's build system supports it but not the other of libraries one might need to deploy. Besides, adding further complexity to the build system sounds like shooting yourself in the foot to me. Maybe the same could be achieved using distinct builds for the architectures as well. But Qt is transitioning to CMake anyway which only supports targeting one platform at a time (as far as I know). So they will likely need to drop their hacks again anyways.
Pinned Comments
hipersayan_x commented on 2021-07-07 15:06 (UTC) (edited on 2021-07-07 15:10 (UTC) by hipersayan_x)
I'll drop this package, I been thinking and there are a lot of strong reasons not to waste any time maintaining it.
KDE doesn't provide an easy way to download the entire Qt source code in a single package, like in the official Qt releases.
Also, KDE doesn't provides tagged versions, I've to keep tracking manually the latest commits, or converting it to a git package.
It will require to split this package into 47x4 packages, 47 Qt modules and 4 architectures to maintain, that's 188 packages to maintain, absurd!
Cloning a git repository is slower than just downloading a source package file, making the build even much slower and painful.
Is a lot of work for something that will be dead in 1 year or 2 at most.
Good luck to the one that will step up to take care of this monstrosity, to the rest of developers, don't be lazy and consider switching to Qt6.