In reply to @mequbic:matrix.org
Does cabal not support GHC2024 yet?

GHC2024 is only supported if you have at least version 9.10 of ghc, according to a warning when initialising projects with cabal. nix installs 9.8.4 by default though.

When I explicitly install a newer version using nix-shell -p cabal-install haskell.compiler.ghc9122, which installs ghc version 9.12.2, it works.

(Well "works": I get a different error, which could be resolved with changing base ^>= 4.19.2.0 to base >= 4.19.2.0 in mandelbrot.cabal, but that's a different topic)

In reply to @le:4d2.org

GHC2024 is only supported if you have at least version 9.10 of ghc, according to a warning when initialising projects with cabal. nix installs 9.8.4 by default though.

When I explicitly install a newer version using nix-shell -p cabal-install haskell.compiler.ghc9122, which installs ghc version 9.12.2, it works.

(Well "works": I get a different error, which could be resolved with changing base ^>= 4.19.2.0 to base >= 4.19.2.0 in mandelbrot.cabal, but that's a different topic)

To have all of this in your shell.nix, change

myPkg = pkgs.haskellPackages.callCabal2nix "mandelbrot" src {};

to

myPkg = pkgs.haskell.packages.ghc9122.callCabal2nix "mandelbrot" src {};

In reply to @aidalgol:matrix.org
I need some help understanding this build failure from PR 424162.

In reply to @teoc:matrix.org
should be actual compiler, I can rebase my patch for ghc-9.12

In reply to @mangoiv.:matrix.org
I fear then it won’t apply to earlier versions. Building with ghc 9.10 but can only continue when my laptop is idle because while it’s building GHCs it’s unusable

In reply to @aidalgol:matrix.org
And then when I have a fix, do I create a PR to marge into haskell-updates?

Leaving out the confusing mess that is splicing, cross starts by setting buildPlatform and hostPlatform differently when initialising Nixpkgs.
Nixpkgs will then produce multiple "layers" of packages.
There are the top-level packages, which run on the host platform and (if applicable) target the host platform.
Under buildPackages i.e. pkgsBuildHost are packages that run on the build platform and (if applicable) target the host platform.
More rarely, you might need to use pkgsBuildBuild for compilers that target the build platform.
Finally, there is targetPackages i.e. pkgsHostTarget for when you're inside buildPackages and need to reference a top-level package.

So with WASM, pkgsCross.wasm32-unknown-none is the top-level layer that builds on your native system and runs on WASM.
pkgsCross.wasm32-unknown-none.ghc is a GHC cross-compiled to run on WASM.
pkgsCross.wasm32-unknown-none.buildPackages.ghc is a GHC cross-compiler that runs on your native system and targets WASM.
pkgsCross.wasm32-unknown-none.pkgsBuildBuild.ghc is a GHC that runs and targets your native system.
pkgsCross.wasm32-unknown-none.haskellPackages.pandoc is Pandoc compiled to run on WASM (i.e. compiled with buildPackages.ghc).

In reply to @maralorn:maralorn.de
I would like to conceptually grok how cross-compilation works in nixpkgs. My understanding is that "buildPackages" is meant to contain build outputs which are meant to be used on the build system, and they can be used to produce build outputs meant to be run on the target system. What I am wondering is this: When we want to cross-compile to wasm then we need to take a ghc which has wasm als compile target. But that ghc I think runs on the build system and thus belongs to buildPackages right? But when we replace the ghc in buildPackages with a wasm-targeting one, then those haskellBuildPackages are kinda broken because they should be compiled for and usable on the build plattform, so "replacing" the ghc is kinda wrong is it?

I am asking because I am trying to understand this line: https://github.com/ners/nix-wasm/blob/795efcfb8f8e98d7084be5da354cbe850f5834da/flake.nix#L48 Which works, but it does e.g. lead to ghcWithPackages not working for wasm cross.

buildPackages contains cross-compilers, so that line doesn't look too out of place.
I'm not sure what exactly the haskell.override is doing.
(In my experience, extending prev.haskell without override works, though I was redefining all of compiler and packages.)

The wasm32-wasi-ghc-9_12 doesn't have any passthru attributes, which Nixpkgs needs to do various things correctly.
The author has already realised this by adding targetPrefix to it, but there might be others needed to make ghcWithPackages work.