| 25 Apr 2025 |
 thirdofmay18081814goya | guess it can't hurt to try both (except for the time expense lol) | 15:06:37 |
 maralorn | The two main advantages I see in haskell.nix are clean derivations for cross-plattform and non-default flags and the possibility to consume a cabal/stack generated build plan. Both of those features I would really want upstreamed into cabal2nix. imo, however if you can get your builds to build without them it is probably not worth the overhead. You are depending on nixpkgs anyway. | 15:16:12 |
| maralorn | My impression is that haskell.nix is a good fit for larger projects/companies where reliably targeting many plattforms is a requirement, it is unrealistic for every team member to be well-versed in the manual dependency resolution dance of nixpkgs, caching is a non-issue because they need their own cache anyway and upstreaming is not a priority. | 15:20:20 |
| maralorn | * My impression is that haskell.nix is a better fit for larger projects/companies where reliably targeting many plattforms is a requirement, it is unrealistic for every team member to be well-versed in the manual dependency resolution dance of nixpkgs, caching is a non-issue because they need their own cache anyway and upstreaming is not a priority. | 15:20:51 |
| maralorn | But I have not actually used haskell.nix a lot. | 15:21:25 |
 toonn | The Nixpkgs infra makes it hard to pick versions of deps. That applies for small projects more than large projects, IMO. | 15:25:28 |
| thirdofmay18081814goya | hm I see | 15:39:30 |
| thirdofmay18081814goya | lots to read and test out heheh, tyvm for comments | 15:39:42 |
|  aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) joined the room. | 15:39:50 |
 shapr | We used haskell.nix when I worked at SimSpace. We had one employee who spent all their time on the nix toolchain things. It was worth it! | 15:41:10 |
| shapr | For my own use, stock nixpkgs is fine 99% of the time. | 15:41:25 |
| 26 Apr 2025 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | I'm trying to build our haskell ecosystem part in Nixpkgs on loongarch64. loongarch64 support of haskell is only available after ghc>=9.12 and llvm>=18. Currently our default is ghc 9.6 and llvm 15. | 03:54:06 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | There are two issues here, the less significant issue is that I need to change the default ghc version to 9.12, but I don't know how compatible our stackage is with this version. | 03:55:29 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | The bigger issue is that I can't rely on 9.10 to compile 9.12, like we do now, so I should package a binary distribution of 9.12, but upstream does not publish binary distribution built for loongarch64. | 03:56:56 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | Oh, there's hadrian bootstrap source, but upstream only publishes 9.8 and 9.10 | 04:01:30 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | Wait, seems like the support is older than I got, I just have to get a set of patches | 04:10:25 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @aleksana:mozilla.org
Oh, there's hadrian bootstrap source, but upstream only publishes 9.8 and 9.10 It's not ghc with hc files generated 😣 | 04:38:25 |
 Alex | In reply to @aleksana:mozilla.org
The bigger issue is that I can't rely on 9.10 to compile 9.12, like we do now, so I should package a binary distribution of 9.12, but upstream does not publish binary distribution built for loongarch64. You can cross-compile 9.4 using the LLVM backend and use that to natively compile newer versions. | 09:10:30 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @alex:tunstall.xyz
You can cross-compile 9.4 using the LLVM backend and use that to natively compile newer versions. There's no loongarch64 support in ghc94 at all | 09:15:18 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | I'm trying to cross compile ghc 9.8.4 with no luck | 09:15:37 |
| Alex | It doesn't matter. You can use unregisterised mode. | 09:15:40 |
| Alex | AFAIK cross is completely broken with Hadrian.
If you can get it to work, I'd love to know how. | 09:16:05 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @alex:tunstall.xyz
AFAIK cross is completely broken with Hadrian.
If you can get it to work, I'd love to know how. I don't write haskell at all tbh | 09:16:27 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @alex:tunstall.xyz
It doesn't matter. You can use unregisterised mode. Do we have nix code for unregisterised mode already? | 09:17:14 |
| Alex | Unregisterised GHC relies entirely on the C compiler and needs no knowledge of the target architecture. | 09:17:16 |
| Alex | Yes, you can set it explicitly, but GHC will do so automatically if it doesn't recognise the architecture anyway. | 09:17:49 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | Oh so pkgsCross.loongarch64-linux.haskell.packages.ghc984.ghc is hadrian | 09:21:05 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | I have to use pkgsCross.loongarch64-linux.haskell.packages.native-bignum.ghc984.ghc and temporarily override enableUnregisterised | 09:22:57 |
 magic_rb | Youre porting ghc to loongarch? | 09:26:26 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @magic_rb:matrix.redalder.org
Youre porting ghc to loongarch? Not porting, just making it work in nixpkgs | 09:26:42 |
