| 15 Sep 2025 |
 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 |
