| 15 Sep 2025 |
 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 |
 Alex | In reply to @sternenseemann:systemli.org
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).
we don't have hugs
All it needs is an older GCC than the Nixpkgs default (or for someone to patch it to work with newer GCC). | 13:48:08 |
| sterni (he/him) | as long as it's not older than what we have in nixpkgs we can just package that shouldn't be a problem | 13:48:38 |
| sterni (he/him) | I guess still it may be easier to get MicroHs with GHC to work first before figuring out hugs, but you know that better. | 13:49:01 |
 emily | how old | 13:49:12 |
| emily | we will be dropping GCC 14 in 26.05 | 13:49:21 |
| emily | er | 13:49:34 |
| emily | 13 | 13:49:36 |
| emily | so I strongly recommend patching or -Wno-error over pinning an old GCC | 13:49:45 |
| emily | (it needs Lennart's branch of Hugs right? presumably we could just send PRs and treat that as the upstream) | 13:50:11 |
| Alex | Right now I'm using gcc13Stdenv, so I may need to take a closer look at the error from newer GCCs... | 13:50:16 |
| Alex | In reply to @emilazy:matrix.org
(it needs Lennart's branch of Hugs right? presumably we could just send PRs and treat that as the upstream) Sounds good to me. | 13:50:46 |
| emily | yeah I would prefer a moratorium on adding more GCC 13 at this point :P | 13:50:47 |
| emily | it's not hard to adapt stuff to newer versions | 13:50:54 |
| emily | just slightly tedious sometimes | 13:50:59 |
