Investigate if we can make it use the generic builder from nixpkgs

[jappeace]

The current way we link for ios and android is kinda weird.

It copies the sources of user code and client into a giant library
and just link in place.

Maybe because I attempted to use backpack at some point that it got this custom derivation.
but it could also be that we just can't make an executable with the generic builder without calling ghc directly?
If that's the case I should investigate how to repair cabal so we can do that.

[jappeace-sloth]

Having explored the nix build setup thoroughly, I believe the custom derivation is the correct approach and switching to the generic nixpkgs Haskell builder would be very difficult, if not impossible, given the current state of cabal.

The core issue is that hatter's mobile builds require things the standard builder simply can't express:

1. Pre-GHC NDK compilation

JNI bridge C files must be compiled by NDK clang before GHC runs, with `-DJNI_PACKAGE` macros. The standard builder compiles C sources as part of cabal's build phase, not separately. Consumer JNI bridges (`extraJniBridge`) are injected at nix-level — cabal has no concept of this.

2. Whole-archive linker control

Boot packages (RTS, base, ghc-prim) must be `--whole-archive`'d into the `.so` because Android can't find GHC's separate shared libraries at runtime. Other packages link normally. The standard builder doesn't support per-package linker flag toggling, and cabal's `ld-options` application is inconsistent (haskell/cabal#10789).

3. C bridge separation from Template Haskell

Bridge `.o` files reference FFI exports that iserv-proxy can't resolve, so they must be compiled separately and linked via `-optl`, not included in cabal's build graph. There is no cabal mechanism for this separation.

4. iOS `ghc -staticlib` + mac2ios patching

A completely different output format that the standard builder doesn't target. The `-staticlib` flag produces a static archive that gets merged with gmp via libtool and patched for iOS architecture — none of which cabal supports.

5. Dynamic library path discovery

Library paths are discovered at build-time via `find` over hash-suffixed directories. This runtime configuration isn't expressible in cabal metadata.

6. iserv-proxy injection for Template Haskell

Cross-compilation TH requires `-fexternal-interpreter` with a QEMU-wrapped iserv-proxy-interpreter. Cabal has no `run-tool-depends` (haskell/cabal#5411) to declare build-machine tools, and no cross-compilation conditional (haskell/cabal#9321).

Cabal issues that would need fixing first

The `foreign-library` stanza was the intended cabal mechanism for this use case, but it's incomplete:

• Support standalone foreign libraries on Linux haskell/cabal#4827 — Foreign libraries on Linux are not standalone (still require GHC's RTS shared libs)
• Build shared libraries without any dynamic dependencies haskell/cabal#1688 — Can't build shared libraries without dynamic dependencies
• Cannot install foreign library haskell/cabal#8890 — Can't `cabal install` a foreign-library
• foreign-library doesn't respect pkgconfig-depends haskell/cabal#4878, foreign-library does not apply pkgconfig-depends cflags to c-sources when using v2-build haskell/cabal#11297 — `pkgconfig-depends` ignored in foreign-library
• HookedBuildInfo doesn't support foreign-library haskell/cabal#7227 — `HookedBuildInfo` doesn't support foreign-library
• foreign-library: Which RTS to link against? haskell/cabal#4815 — No way to specify which RTS to link into a foreign library

Cross-compilation support is also incomplete:

• build Setup.hs with local compiler when cross-compiling haskell/cabal#1493 — Setup.hs compiled with wrong compiler during cross-compilation
• Cabal shouldn't try to build executables for iOS haskell/cabal#1988 — Cabal tries to build executables for iOS (impossible)
• Cabal doesn't seem to call the correct hsc2hs when cross-compiling haskell/cabal#5760 — Wrong hsc2hs invoked during cross-compilation
• Conditional test for detecting cross-compilation haskell/cabal#9321 — No conditional for detecting cross-compilation in `.cabal` files

Build hooks / custom C compilation:

• cabal-hooks: Demand rules that produce libraries haskell/cabal#10791 — Setup hooks can't produce library artifacts
• Allow pre-build rules to generate extra source files haskell/cabal#11607 — Pre-build rules can't generate extra source files
• Per file options haskell/cabal#10552 — No per-file compiler options (NDK clang vs host GCC)
• cc-options do not get passed to GHC haskell/cabal#4435, Cabal doesn't pass cc-options to GHC when compiling ordinary Haskell sources haskell/cabal#9801 — cc-options not forwarded to GHC properly

Recommendation

The custom derivation is the right tool here. The alternative would be patching cabal itself to support Android/iOS shared library targets with JNI bridge injection, which is essentially what hatter's nix build already does — a cabal replacement for the cross-compilation link phase.

This could be revisited if the `foreign-library` stanza matures (especially haskell/cabal#4827 and haskell/cabal#1688), but that looks to be a long way off.

[jappeace]

t-thanks I told you to not incldue that issue list but I guess the cat's out of the bag now...