Package Details: android-armv7a-eabi-qt5 5.15.2-2

Git Clone URL: https://aur.archlinux.org/android-armv7a-eabi-qt5.git (read-only, click to copy)
Package Base: android-armv7a-eabi-qt5
Description: Qt 5 for Android
Upstream URL: https://www.qt.io
Licenses: GPL3, LGPL
Groups: android-qt5
Submitter: hipersayan_x
Maintainer: None
Last Packager: hipersayan_x
Votes: 18
Popularity: 0.000000
First Submitted: 2018-11-22 19:15 (UTC)
Last Updated: 2021-03-14 20:02 (UTC)

Dependencies (26)

Sources (4)

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.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 12 Next › Last »

hipersayan_x commented on 2020-01-08 12:42 (UTC)

Yes, that is.

Martchus commented on 2020-01-08 09:44 (UTC)

Just for the record, likely that's where you've got it: https://bugreports.qt.io/browse/QTBUG-80756

Martchus commented on 2020-01-07 19:14 (UTC) (edited on 2020-01-07 19:16 (UTC) by Martchus)

Thanks, I'll try that when there's a patch for the CMake issue. And I'm afraid that's not the only problem with 5.14: https://lists.qt-project.org/pipermail/interest/2020-January/034372.html

hipersayan_x commented on 2020-01-07 18:26 (UTC)

Because you forgot to add

export ANDROID_TARGET_ARCH="${ANDROID_ABI}"

in your PKGBUILD. I had the same problem, I don't remember where I get the solution but it worked :-P

Martchus commented on 2020-01-07 16:04 (UTC) (edited on 2020-01-07 16:05 (UTC) by Martchus)

I'm wondering why you don't need the sed command I've mentioned in this ticket: https://bugreports.qt.io/browse/QTBUG-80938

For me it otherwise tries to configure this for aarch64 (which obviously breaks when linking against armv7a-eabi libs). And when reading that the build system is actually supposed to run the configuration only for one hardcoded architecture I've just though WTF, seriously?

Martchus commented on 2019-12-31 15:41 (UTC)

@Kicer And you are right about the platform package. My version of this package has this dependency because it wouldn't build otherwise. I suppose the exact version which is required is determined by the platform version one configures Qt to target. Hence I'm using a variable in my PKGBUILD file for it.

By the way, the reason the master branch of my PKGBUILDs repo still has version 5.13 and not 5.14 is because of that CMake regression.

Martchus commented on 2019-12-31 15:34 (UTC)

@Kicer This is a known bug, see my comment on the aarch64 package.

Kicer commented on 2019-12-31 10:36 (UTC)

After update to Qt5.14 there is a lot of directories missing in /opt/android-libs/armv7a-eabi/lib/cmake/ (like Qt5Widgets or Qt5Network, but also many many others)

Kicer commented on 2019-12-31 08:54 (UTC)

I believe dependency to android-platform-22 should be added here, as without it package won't compile. Btw I cannot find information why exactly version 22 of platform is required. Is it described anywhere?

Martchus commented on 2019-10-22 21:55 (UTC)

By the way, the KDAB blog posts mentions the new build option -android-abis which is now required to keep things sane and simple.

Apparently my assertion about CMake is not correct: https://cristianadam.eu/20191012/building-multiple-configurations-with-cmake-in-one-go

This works because with Clang the same compiler executable can be used and the architecture is just an argument. Still, it sounds like shooting yourself in the foot. E.g. you also need to find all the dependencies for all theses configurations at the same time.

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 12 Next › Last »