| 15 Sep 2025 |
 MangoIV | that seems absurd to me | 13:36:23 |
 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 |
| emily | I would personally only expose a fully bootstrapped one as first-class but it's not my decision to make. probably having a withHugsBootstrap param on the MicroHs derivation and microhs takes microhs as a build input that you override to have withHugsBootstrap or something | 13:42:33 |
| MangoIV | Also why does hadrian not support proper incremental build support? | 13:42:37 |
| emily | I mean whatever makes the Nix simplest really | 13:42:41 |
| MangoIV | shake does that out of the box? | 13:42:43 |
| emily | but even for bootstrapping GHC I think you'd want the full MicroHs | 13:42:54 |
| sterni | I guess nothing inherently, it's just that it's an incomplete reimplementation of the old make build system with some arbitrary improvements. It regressed a bunch of stuff that hasn't been fixed to this day. I find it much more unwieldy to work with and understand because it uses kind of fuzzy abstractions and it is hard to inspect what it decides to do internally and even harder to override certain aspects of its behavior. Also there are questionable design decisions like always building an bindist instead of installing directly (this sounds good in theory, but is not really a good idea). | 13:43:00 |
| emily | because like, why not be uniform | 13:43:03 |
