| 29 Jan 2025 |
 maralorn | That’s a good point. | 20:46:26 |
| maralorn | How does that even?^^ | 20:46:42 |
| maralorn | Like with which stage are boot packages compiled? | 20:46:56 |
| maralorn | I mean ghc the lib cannot be compiled by itself of the same stage, right?^^ | 20:47:22 |
 hellwolf | In reply to @maralorn:maralorn.de
As always I have to ask: Why built hlint with ghc910? hlint will work perfectly fine when compiled with older ghcs. If you need support for new syntax the relevant version is that of ghc-lib-parser. some extensions are 9.10+, hlint wouldn't support it. | 20:48:01 |
| hellwolf | * some extensions are 9.10+, hlint built for other version of ghc wouldn't support it. | 20:48:19 |
| hellwolf | that's my understanding | 20:48:23 |
| hellwolf | * some extensions are 9.10+, hlint built for other version of ghc libs wouldn't support it. | 20:48:31 |
| maralorn | Yeah, true. | 20:48:59 |
| hellwolf | And I'm not shy away from using the latest the greatest... so | 20:51:40 |
| hellwolf | but I circumvented and avoided TypeaAbstractions in functions (a ghc9.10 addition) for now | 20:52:42 |
| maralorn | Or is that some kind of fix point where we link a lib compiled with ghc stage-n directly against the lib ghc stage-n? | 20:53:18 |
| maralorn | Oh, boy, why do I know so little about this. đŸ˜„ | 20:53:31 |
| maralorn | Really looking forward to using that one. | 20:53:50 |
 Teo (he/him) | In reply to @maralorn:maralorn.de
Or is that some kind of fix point where we link a lib compiled with ghc stage-n directly against the lib ghc stage-n? Iirc stage-2 GHC links against libraries built by stage1 GHC, but that's OK because they are practically the same anyway | 21:58:11 |
| Teo (he/him) | There's this explanation in the Hadrian docs but even with that it's still quite confusing https://gitlab.haskell.org/ghc/ghc/-/tree/master/hadrian#staged-compilation | 22:01:25 |
| maralorn | Ah, thanks that actually helps me. | 22:16:28 |
| maralorn | So even "reinstallable" dependencies of ghc cannot actually be reinstalled when used together with ghc? Because ghc stage 2 is linked with mtl stage 1 and thus will collide with mtl stage 2? | 22:19:49 |
 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 |
