| 15 Sep 2025 |
emily | implicit parameters don't screw with the semantics of normal type classes | 13:37:03 |
MangoIV | yeah but they're special cased in all kinds of ways | 13:37:24 |
emily | is there an obstacle to still using Hadrian to build one stage but then layering those with Nix? | 13:37:39 |
emily | if that could solve cross then it feels like an easier intermediate step | 13:37:51 |
MangoIV | you can just --freeze-stagen | 13:38:18 |
sterni | more packages are just normal cabal packages in tree now, something that John Ericson has worked on. There is an effort to utilize this for building GHC https://github.com/stable-haskell/ghc/pull/89, though they are using cabal.project files instead of Nix which apparently also causes its own issues. | 13:38:34 |
emily | well I'm guessing it's tricky in some way or it'd have already been done | 13:38:40 |
teo (they/he) | I don't think so! I think that would be a great way to get started. Build stage1 with Hadrian and then let nix build stage2. Or even easier, build stage2 with hadrian and then build a stage3 with nix | 13:38:43 |
MangoIV | what's the point of building GHC with cabal, btw? there are some people that want that | 13:39:03 |
emily | I was thinking build stage2 and stage3 with Hadrian but just, separately | 13:39:13 |
teo (they/he) | There is a CI test that builds a stage3 GHC with cabal-install but it has been broken for silly reasons for ages on the GHC gitlab | 13:39:28 |
emily | but I'm guessing it's not wired up for this | 13:39:29 |
teo (they/he) | yeah that would also be good | 13:39:42 |
emily | er sorry I meant stage1 and stage2 | 13:39:45 |
emily | the question is whether that would work for a cross-compiled GHC | 13:40:05 |
emily | (again as distinct from a cross-compiling GHC) | 13:40:16 |
teo (they/he) | I think the main advantages to Hadrian are to do with devex like nice recomp support, etc. And when you are a distributor all you are left with is complexity and cost | 13:40:40 |
Alex | In reply to @emilazy:matrix.org we talked about this recently and I suggested a package set would be interesting for exploring future GHC bootstrap How should I structure this btw?
Should Nixpkgs expose:
- Any Hugs-interpreted boot tools (probably not, likely fragile)?
- Stage 1 compiler built via Hugs (should be as good as a stage 2)?
| 13:40:43 |
emily | I didn't realize it was that close to "just" being cabal-installable | 13:40:46 |
emily | I assumed you'd need a lot more glue. cool | 13:40:52 |
MangoIV | but it would for sure require support of cabal upstream, right? I don't think that that's a good idea at all tbh. | 13:41:25 |
teo (they/he) | This didn't actually achieve it but we had this MR ages ago: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5965 | 13:42:24 |