| 15 Sep 2025 |
 MangoIV | the tool cannot decide that for you | 13:43:27 |
 teo (they/he) | 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 | 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 (they/he) | 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 | 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 (they/he) | 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 | 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 (they/he) | 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 |
