| 29 Jan 2025 |
 sterni (he/him) | Not sure you'll have to look at the package db entries i guess | 22:34:37 |
| sterni (he/him) | every package that is part of stage1 will also be built in stage2 | 22:34:54 |
 Teo (he/him) | I don't understand it fully but "reinstallability" is mostly a constraint imposed by cabal rather than GHC see mpickering's comments here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13297 | 23:30:51 |
| 30 Jan 2025 |
|  laurynasp joined the room. | 08:59:05 |
|  sem joined the room. | 21:56:33 |
| sterni (he/him) | same difference, really | 22:14:04 |
| sterni (he/him) | it doesn't really matter when practically all software is built using cabal | 22:14:22 |
 maralorn | Does that mea ghc the lib that hls links against is "ghc stage 3" in that explanation. So basically everything we build is build with ghc stage 2 and linked against stage 2? | 22:18:33 |
| maralorn | * Does that mea ghc the lib that hls links against is "ghc stage 3" in that explanation. So basically everything we build is built with ghc stage 2 and linked against stage 2? | 22:18:46 |
| maralorn | * Does that mean ghc the lib that hls links against is "ghc stage 3" in that explanation. So basically everything we build is built with ghc stage 2 and linked against stage 2? | 22:18:58 |
| maralorn | So the mtl exposed in our ghc pkg-db and a hypthetical mtl built with our nix derivation both are "stage 2". The problem is that "ghc" the lib will be linked against the internal mtl and can those not be coherently used with the own-nix-derivation mtl (especially if that’s another version.) | 22:22:20 |
| maralorn | Only solution would be if we could build ghc the library as a normal Cabal package at least in stage 3? | 22:22:57 |
| maralorn | What surprises me slightly from this picture is that I always hammer in the point that HLS needs to be compiled with the same GHC which is used to build the project. But now it seems to me like we are not doing that because HLS is linked againts GHC stage 3, while the project is being compiled by ghc stage 2? | 22:24:31 |
| maralorn | I am not actually saying that this is a reductio ad absurdum I just want to spell it out, that I was missing the full picture before and trying to get my understanding precise. | 22:25:41 |
| Teo (he/him) | In reply to @maralorn:maralorn.de
Only solution would be if we could build ghc the library as a normal Cabal package at least in stage 3? Afaik this is possible and there's a job in the GHC CI that ensures this using this code: https://gitlab.haskell.org/ghc/ghc/-/blob/master/hadrian/src/Rules/CabalReinstall.hs | 22:26:36 |
| maralorn | sterni: Does what I am writing match your understanding? (or at least not contradict it?) | 22:45:49 |
| sterni (he/him) | I'd need to think through it myself honestly | 22:46:48 |
| sterni (he/him) | in any case see also https://gitlab.haskell.org/ghc/ghc/-/tree/master/hadrian?ref_type=heads#staged-compilation | 22:47:00 |
| sterni (he/him) | no I think the packages in a stage are linked against its siblings so the ghc executable and library are just stage2 (i.e. built using stage1) | 22:57:30 |
| sterni (he/him) | default setting of hadrian is to stop after stage2 has been built (i.e. all stage2Packages have been built using stage1). | 22:57:55 |
| maralorn | Okay. So we compile everything with ghc stage 2 but link it against boot packages built in stage 1? And especially we build with ghc stage 2 and link against ghc stage 2. | 22:59:13 |
| sterni (he/him) | hmm though what I'm saying doesn't quite match the picture they have in the readme | 22:59:53 |
| sterni (he/him) | I honestly don't know I'd probably need to take a few days to read the code or idk find a way to dump the build graph from shake | 23:00:17 |
| sterni (he/him) | unfortunately hadrian is magic to a degree because it can sort of load cabal packages so the dependency plumbing is not very explicit | 23:00:57 |
| sterni (he/him) | you can probably make a rube goldberg machine where you have a derivation for just ghc, one for haddock etc., but this stuff really hasn't been designed for that, so who knows how many problems you run into | 23:02:40 |
| sterni (he/him) | I suspect you can get hadrian to do it, but configure won't like all the missing dependencies (for targets you don't want to build) | 23:03:38 |
| maralorn | I really like the metaphor of nix builds as rube goldberg machines. My I can design an alternative visualisation for nom from that. 😄 | 23:09:19 |
| 31 Jan 2025 |
 Alex | In reply to @sternenseemann:systemli.org
default setting of hadrian is to stop after stage2 has been built (i.e. all stage2Packages have been built using stage1). This makes sense, as there's no real benefit to using stage2 over stage1 to build packages outside of build time, which already needs to be spent to build stage2 dependencies.
(If we use version A to boot a version B build, stage1 is built by A and outputs programs built by B, so packages built by it have all of B's performance improvements.) | 08:08:19 |
| maralorn | * I really like the metaphor of nix builds as rube goldberg machines. Maybe I can design an alternative visualisation for nom from that. 😄 | 08:59:47 |
| maralorn | Alex: You mean the results of the stage 1 and the stage 2 compiler are basically identical, stage 2 just compiles faster? | 09:02:30 |
