| 15 Sep 2025 |
 emily | at that point you're basically rewriting Hadrian in Nix right? | 13:34:04 |
| emily | or wait Hadrian doesn't even use Cabal right... | 13:34:11 |
| emily | I can't keep all this stuff straight | 13:34:16 |
 teo (they/he) | This would be great. Whatever happens, it would be great if boot libs were built with nix and weren't special | 13:34:21 |
 MangoIV | hadrian is shake based. | 13:34:41 |
| emily | calling implicit params sugar feels a bit of a stretch to me, it has some pretty weird/deep semantics :) | 13:34:59 |
| emily | but if you mean "can easily be removed much of the time" then fair | 13:35:09 |
 toonn | sterni: What are the problems with Hadrian? | 13:35:41 |
| MangoIV | they are reverse sugar - it's mostly to support HasCallstack... :D | 13:35:47 |
 Alex | In reply to @teoc:matrix.org
This would be great. Whatever happens, it would be great if boot libs were built with nix and weren't special autoconf might give some trouble, but building bootlibs without Hadrian is possible as long as you have a compiler, cabal, and a cpphs implementation. | 13:35:52 |
| 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 | 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 |
