Accept "linux-androideabi" as an alias for Android

[Ericson2314]

Google uses armv7-none-linux-androideabi, analogous to
armv7-unknown-linux-gnueabi for e.g. a 32-bit regular linux.

The existing alias it not a mistake, it is the right one for 64 bit.
Google for that use aarch64-linux-android, analogous to
aarch64-unknown-linux-android for a 64-bi regular linux.

See https://developer.android.com/ndk/guides/standalone_toolchain for
evidence/details.

---

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.
• If the change is docs-only, [ci skip] is used to avoid triggering the build bots.

Please also shortly describe how you tested your change. Bonus points for added tests!

[phadej]

I think we should gate these based on cabal-version / CabalSpecVersion. This affects cabal file format.

cc @hvr

[Ericson2314]

I think in practice this is more likely to fix old packages than break them.

linux-android was added without such a gate https://github.com/haskell/cabal/pull/5199/files, and before that GHC broke things on Cabal's end when it got rid of its notion of iOS and android in https://gitlab.haskell.org/ghc/ghc/commit/cb4878ffd18a3c70f98bdbb413cd3c4d1f054e1f, so it's not like this stuff has been stable at all.

Furthermore, os(android) probably worked for both bit-widths at many point. Just google armv7-linux-android for people using android instead of androideabi on both architectures. Including @angerman in https://medium.com/@zw3rk/a-haskell-cross-compiler-for-android-8e297cb74e8a. It's really only my pedantry that made nixpkgs switch to using androidaebi to match Google and regular arm 32 Linux, which eventually caused me to discover this and send PRs to Cabal and cabal2nix.

I strongly recommend not gating this.

[phadej]

The fact that we were sloppy in the past doesn't justify being sloppy in the future.

Warning: The following errors will cause portability problems on other
environments:
Warning: Unknown operating system name 'linux-androideabi'
Warning: Hackage would reject this package.

The osAliases are part of cabal file format and I'm going to be the strict about their changes. Let's do things properly, even it requires more extensive changes. The more we do it so, the easier future changes will be.

---

I think the right solution is to have separate osAliases: the one used in .cabal files, and the ones used to match against System.Info.os.

• .cabal files list should not be changed easily, and should be documented. We really don't need be able to use mingw32 to mean windows
• latter ones can be changed on need.

Many purposes, tricky to change. Decouple: profit!

---

EDIT: we decoupled Version used for haskell package versions and pkgconfig stuff, and things become a lot more clearer. It's worth it.

[Ericson2314]

Yeah decoupling sound good. I only expect anyone to use anything but os(android). I wouldn't even spend any time advocating anything else to work.

os(linux-android) was just something people started using as a workaround to android not being recognized -- a sort of workdaround that I don't even think works anymore as os(android) || os(linux-androideabi) didn't work when I tried it. In fact, I would recommend you revision that away on Hackage if there's any up there.

[Ericson2314]

Also, does ClassificationStrictness already handle this split? I see Compat used for some cabal files (maybe just older ones), and Permissive used for Haskell implementations.

[Ericson2314]

I used Permissive and Compat for now to avoid changing the Cabal file format, as far as I can tell, and also added linux-androideabihf, which means hardware floating point support.

[3noch]

What's holding this up now?

[phadej]

Merged rebased in #6949

[Ericson2314]

Thanks!