| 24 May 2026 |
 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 |
| alexfmpe | You probably mostly want HLS only for native builds, if nothing else for speed | 12:58:17 |
| alexfmpe | There's no ghci for js backend | 12:58:25 |
| alexfmpe | I don't know if there's conflicts shoving both compiler/package sets in the same nix env, and it also depends on whether you just want the tooling from nix or also the dependencies | 13:00:15 |
| alexfmpe | Safest thing might be to make the native backend the default, and have a separate shell for js builds | 13:01:03 |
| alexfmpe | Past that you're into tinker-with-infra territory | 13:01:35 |
| alexfmpe | This is a bit old in early-adopter terms, but might help as a reference: | 13:05:08 |
| alexfmpe | https://github.com/bfeitknecht/impli/pull/6/changes#diff-93b556800e5bfe30a541d4c38712e88fc5763a362ab43de7446476ed3bddcee0 | 13:05:10 |
| alexfmpe | Well, technically you can throw your package into the nixpkgs haskelloverides, and then nix-build like normal or with pkgsCross.ghcjs | 13:06:11 |
| alexfmpe | But you asked about cabal.project so I assume you meant everyday local dev, not 'prod' build | 13:06:38 |
| tks_123 | Yes, everyday local dev :) But... for everyday local dev, I'd want to... check if the website ... works in the browser (I guess)? | 13:08:19 |
| tks_123 | * Yes, everyday local dev :) But... for everyday local dev, I'd want to... check if the website ... works in the browser. | 13:08:50 |
