| 24 May 2026 |
alexfmpe | js/wasm backends are part of the same codebase as everday ghc | 11:41:33 |
alexfmpe | that said, ghc is not (currently) retargetable, so just like any other cross compilation, you need to re-compile the compiler into one binary per target architecture | 11:42:27 |
alexfmpe | what nixpkgs does is plug the js-backend build into the pkgsCross.ghcjs package set | 11:44:07 |
alexfmpe | /nix/store/f612853p8bbb2zds2q5znzra7kz9qdnk-hello-1.0.0.2
├── bin
│ ├── hello
│ └── hello.jsexe
│ ├── all.externs.js
│ ├── all.js
│ ├── index.html
│ ├── lib.js
│ ├── out.frefs.js
│ ├── out.frefs.json
│ ├── out.js
│ ├── out.stats
│ ├── rts.js
│ └── runmain.js
| 11:44:55 |
alexfmpe | * $ tree $(nix-build -A pkgsCross.ghcjs.haskellPackages.hello)
/nix/store/f612853p8bbb2zds2q5znzra7kz9qdnk-hello-1.0.0.2
├── bin
│ ├── hello
│ └── hello.jsexe
│ ├── all.externs.js
│ ├── all.js
│ ├── index.html
│ ├── lib.js
│ ├── out.frefs.js
│ ├── out.frefs.json
│ ├── out.js
│ ├── out.stats
│ ├── rts.js
│ └── runmain.js
| 11:45:08 |
alexfmpe | $ /result/bin/hello
Hello, World!
$ head -n 5 result/bin/hello
#!/nix/store/q1r7qkrnbhakljr4j228v2yi2874jkl9-nodejs-slim-24.15.0/bin/node
var h$currentThread=null;
var h$stack=null;
var h$sp=0;
var h$initStatic=[];
| 11:45:50 |
tks_123 | Interesting. | 11:46:11 |
tks_123 | is the pkgsCross project managed by you guys, same ones who do haskellPackages? | 11:46:47 |
tks_123 | * is the pkgsCross project managed by you guys on this channel, same ones who do haskellPackages? | 11:46:54 |
alexfmpe | pkgsCross is a nixpkgs-wide thing for cross compilation | 11:46:57 |
alexfmpe | this channel mostly cares about fixes to pkgsCross.foo.compiler.ghc or pkgsCross.foo.haskellPackages.bar | 11:48:05 |
alexfmpe | * this channel mostly cares about fixes to pkgsCross.foo.haskellPackages.ghc or pkgsCross.foo.haskellPackages.bar | 11:48:29 |
alexfmpe | where, long story, that's the ghc that targets <foo> platform, not the one running on <foo> | 11:49:21 |
alexfmpe | well, pkgsCross.ghcjs is a special case mostly shoehorned into old ghcjs scaffolding, nobody else cares about that platform | 11:50:13 |
tks_123 | In reply to @alexfmpe:matrix.org well, pkgsCross.ghcjs is a special case mostly shoehorned into old ghcjs scaffolding, nobody else cares about that platform hmm, but you wrote pkgsCross.ghcjs.haskellPackages.hello above. Is the "ghcjs" some old GHCJS thing then? | 11:51:19 |
tks_123 | "nobody else", including folks in this channel? | 11:51:55 |
alexfmpe | pkgsCross.ghcjs just means https://github.com/NixOS/nixpkgs/blob/258544fde350341c6b2776bbcfb744eb4cc9d3d5/lib/systems/examples.nix#L471
which used to be interpreted as "build with ghcjs", then switched to "build with ghcjs if ghc < 9 or js backend otherwise" and now is only js backend | 12:05:20 |
alexfmpe | nobody else but this channel cares about the ghcjs package set | 12:05:43 |
alexfmpe | Redacted or Malformed Event | 12:06:04 |
alexfmpe | * nobody else but this channel cares about working on the ghcjs package set itself | 12:06:40 |
alexfmpe | * the only ones that cares about the ghcjs package set itself are maintainers of it (this channel), or consumers that grab their deps with nix | 12:08:20 |
alexfmpe | I meant it's a special case amongs nixpkgs platforms as only ghc uses it, whereas most other pkgsCross.foo aren't specific to a language/compiler, since y'know, it's just a target platform | 12:13:10 |
tks_123 | alexfmpe ok thank you for clarifying | 12:19:46 |
tks_123 | This is very nice. Lots has happened in the past year | 12:22:04 |
alexfmpe | as for wasm backend, IIUC it has a lot of forked/vendored deps so https://github.com/NixOS/nixpkgs/pull/225000 never really got anywhere and ghc-wasm-meta is the main distribution method: https://gitlab.haskell.org/haskell-wasm/ghc-wasm-meta#getting-started-as-a-nix-flake | 12:28:01 |
tks_123 | alexfmpe As for HLS (vscode, etc.) should I put js backend programs and normal backend programs into different .cabal projects somehow? So HLS/cabal (somehow) knows which backend to use? (I'm assuming you can put both normal haskellPackages and and pkgsCross.ghcjs.haskellPackages into the same nix environment?) | 12:56:04 |
tks_123 | * alexfmpe As for HLS (vscode, etc.) should I put js backend programs and normal backend programs into different .cabal projects somehow? So HLS/cabal (somehow) knows which backend to use?I'm assuming you can (somehow) put both normal haskellPackages and and pkgsCross.ghcjs.haskellPackages into the same nix environment?) | 12:57:10 |
tks_123 | * alexfmpe As for HLS (vscode, etc.) should I put js backend programs and normal backend programs into different .cabal projects somehow? So HLS/cabal (somehow) knows which backend to use?I'm assuming you can (somehow) put both normal haskellPackages and and pkgsCross.ghcjs.haskellPackages into the same nix environment?) | 12:57:13 |
tks_123 | * alexfmpe As for HLS (vscode, etc.) should I put js backend programs and normal backend programs into different .cabal projects somehow? So HLS/cabal (somehow) knows which backend to use? I'm assuming you can (somehow) put both normal haskellPackages and and pkgsCross.ghcjs.haskellPackages into the same nix environment? | 12:57:24 |
tks_123 | * alexfmpe As for HLS (vscode, etc.) should I put js backend programs and normal backend programs into different .cabal projects somehow? So HLS/cabal (somehow) knows which backend to use? (I'm assuming you can (somehow) put both normal haskellPackages and and pkgsCross.ghcjs.haskellPackages into the same nix environment?) | 12:57:36 |