| 15 Sep 2025 |
 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 (he/him) | 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 (he/him) | 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 |
| MangoIV | and you don't get around the freeze-stage-n thing anyway because it's just a user choice of whether or not recompiler the respective boot compiler | 13:43:20 |
| MangoIV | the tool cannot decide that for you | 13:43:27 |
| Teo (he/him) | My view is that if people want to make it build with cabal-install, then that leads to better code in GHC since we make fewer assumptions. And it just means that stuff gets made nicer | 13:44:12 |
| sterni (he/him) | It kind of boils down to that, from a packager's perspective, make is understood software and you know how to work with it and debug it. Hadrian is just too smart and a bit of a black box. I think the motivation was that people were getting scared to change the make build system since it was getting to complicated and unwieldy, but hadrian did not significantly simplify things as far as I can tell. | 13:44:37 |
| Teo (he/him) | Yeah good q. I feel like people ran out of steam right? And the main Hadrian person was hired by Jane Street | 13:44:43 |
| sterni (he/him) | I mean all the packages have the semantics of Cabal packages already so you are just simplifying stuff as much as possible if you do that. | 13:45:08 |
| MangoIV | but cabal can indeed not build GHC, can it? | 13:45:26 |
| MangoIV | like these are required conditions, but not sufficient ones | 13:45:53 |
| Teo (he/him) | the IOG folks implemented this, and it required very few changes. Loads of work is required for cabal to have proper cross support but that's separate | 13:45:58 |
| MangoIV | and GHC is in fact special | 13:46:13 |
| sterni (he/him) | I would just start with adding a MicroHs package set built with GHC as we don't have hugs and then just iterate on that; maybe add hugs separately, have a hugs package set (if that even makes sense). | 13:46:17 |
| Teo (he/him) | mostly because all the tough work had already happened upstream | 13:46:18 |
| MangoIV | it's not like it's any other cabal package | 13:46:19 |
| MangoIV | that's for one stage though, right? | 13:46:58 |
| Teo (he/him) | nah they have a cabal project for each stage | 13:47:21 |
| Teo (he/him) | https://github.com/stable-haskell/ghc/pull/94/files | 13:47:50 |
| sterni (he/him) | Yeah, it seems the wiring it up is the problem at the moment with cabal(-install) alone, but Nixpkgs has an easier time there. | 13:47:58 |
| MangoIV | I see- so the idea is to just have some script that wrap around cabal | 13:48:03 |
