| 15 Sep 2025 |
 MangoIV | i don't understand how it came to be that they exposed that stuff but are reluctant to make withDict work for data dicts | 13:36:13 |
 emily | building libraries separate from compilers and never mixing multiple compiler build/host/target builds in one derivation is all I want in this world 🙏 | 13:36:22 |
| 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 (he/him) | 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 (he/him) | 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 (he/him) | 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 (he/him) | 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 (he/him) | 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 (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 |
