| 5 Apr 2025 |
 emily | it's getting a GHC in the first place | 08:32:46 |
| emily | how is GHC 4 built? | 08:32:52 |
 Divya | In reply to @emilazy:matrix.org
how is GHC 4 built? GHC 4 is bootstrapped from source. | 08:35:01 |
| emily | huh. how? Hugs? | 08:42:20 |
 terrorjack | from generated .hc sources actually: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/haskell.scm#n221 | 08:42:30 |
| emily | ok. that's not from source :) | 08:42:48 |
| emily | but makes sense | 08:42:53 |
| Divya | Yeah from HC | 08:43:02 |
| emily | that's not source. that's compiler output | 08:43:12 |
| Divya | Indeed. Someday I need to sit down and do the chain from Hugs. It's sad that Haskell hasn't taken care of this. | 08:44:49 |
| Divya | Have you guys talked to the GHC folks? | 08:45:05 |
| emily | it's not as simple as chaining from Hugs, people have tried but it requires a lot of patching to even start getting anywhere | 08:46:57 |
| Divya | In reply to @emilazy:matrix.org
it's not as simple as chaining from Hugs, people have tried but it requires a lot of patching to even start getting anywhere Are the people from the Nix community? From Guix, 2-3 people have been trying to do this. | 09:15:10 |
| emily | mostly not, since Nixpkgs has bigger bootstrapping issues :) | 09:15:36 |
| emily | (and though we might use complicated bootstrap chains to verify binaries, it's unlikely we'd put them into production, since chasing through a dozen GHC builds on every staging-next cycle would be too painful. I'm not sure how Guix copes with that kind of thing tbh) | 09:16:28 |
| Divya | In reply to @emilazy:matrix.org
(and though we might use complicated bootstrap chains to verify binaries, it's unlikely we'd put them into production, since chasing through a dozen GHC builds on every staging-next cycle would be too painful. I'm not sure how Guix copes with that kind of thing tbh) I don't think one has to necessarily do that. You'd only have to bootstrap a particular version from a previous one and then just "inherit" that for the next versions. | 09:19:44 |
| emily | but when you rebuild core parts of the toolchain, you need to do the bootstrap all over again | 09:20:58 |
 linj | In reply to @divyaranjan:matrix.org
Are the people from the Nix community? From Guix, 2-3 people have been trying to do this. @alex:tunstall.xyz has done some work | 09:22:47 |
 hellwolf | In reply to @emilazy:matrix.org
but when you rebuild core parts of the toolchain, you need to do the bootstrap all over again wouldn't you freeze the bootstrapped one to a git commit and never touch it again? | 09:27:09 |
| emily | let's say you build GHC 4 with Hugs compiled with GCC 14 | 09:27:42 |
| hellwolf | * wouldn't you freeze the bootstrapped one to a git commit (of guix pkg? or nixpkgs) and never touch it again? | 09:28:04 |
| emily | then when you bump GCC to 15, you need to build GHC 4 with Hugs compiled with GCC 15 | 09:28:08 |
| emily | ca-derivations would allow short-circuiting once you get to a bit-identical binary output, but that might never happen, e.g., because glibc store path changed | 09:28:10 |
| hellwolf | i see. i can see running old bin in a new container as a workaround | 09:29:19 |
| Divya | In reply to @emilazy:matrix.org
then when you bump GCC to 15, you need to build GHC 4 with Hugs compiled with GCC 15 Or, you just have Hugs be built with GCC 14? We always have multiple versions of GCC around. | 09:30:13 |
| emily | ok, but GCC 14 itself changed because glibc got updated | 09:31:08 |
| emily | it's true that you could pin an entire separate copy of Nixpkgs (and pay the evaluation cost for an entire separate package tree for everything that uses GHC, and then that multiplies because there are multiple bootstraped packages, etc.) | 09:31:34 |
| emily | at that point you're also multiplying the amount of source that needs to be trusted for the bootstrap too though | 09:31:51 |
| emily | and the compiler might have bugs on a certain architecture, or glibc with a new kernel, …, so you do not actually want to pin those things forever for the same reason you want to upgrade packages in general | 09:32:14 |
| Divya | Not sure about how it happens in Nixpkgs, but it's common in Guix to have it this way. The package tree gets evaluated only when built. I can create a package tree separate for GHC 9.2 to 9.12 without the previous package tree being affected. And if you need to change something later, you can always keep the older one separately in another package for that package tree. Maintenance is relatively easier. | 09:36:53 |
