<angerman>
tdiesler: we are running into this as well. It appears to be anix bug
<tdiesler>
@angerman I can partially build cardano-node with plain nix on x86_64 and arm64, only that it fails for some haskell package incompatibility i.e. the sort of thing that haskell.nix is trying to solve.
<tdiesler>
IOW, plain nix manages to install ghc + cabal into my env/shell only that they are not usable to build cardano-node. With haskell.nix it fails to even build ghc + cabal
<tdiesler>
I'm wondering, why can nix build ghc-8.10.3 on arm64 but haskell.nix cannot?
<tdiesler>
@angerman thx for the cross link
hekkaidekapus{ has quit [Ping timeout: 268 seconds]
hekkaidekapus{ has joined #haskell.nix
<angerman>
tdiesler: it’s a nix issue :-/ you can even cross compiler binaries just fine. The arming cardano TG channel js links to static builds.
<angerman>
tdiesler: it’s rather frustrating, but Haskell.nix is a pretty heavy stress test.
<tdiesler>
@angerman do you think its worth trying the unstable nixpgs channel or is it totally independent of nix packages and a nix base impl issue?
<angerman>
tdiesler: someone at IOG just tried that as well as a bunch of other combinations. Nothing works so far :-/
<tdiesler>
There seems to be a lot of (legacy) cruft in haskell.nix too. How about a "fresh start" of haskell.nix with a narrow focus on some selected projects (i.e. cardano-node, wallet, etc). this could happen on some "multiarch" branch which over time becomes the default. It would have arm64 support built-in from the start.
<tdiesler>
@angerman ^^^
<angerman>
tdiesler: eh? Cruft?
<angerman>
tdiesler: Haskell.nix just pushes the boundaries of what nix can do pretty hard. I don’t think we can actually remove anything while retaining the functionality.
<tdiesler>
@angerman like support for outdated ghc versions maybe. The existing codebase could be thought as "x86_64" only, going forward haskell.nix may want to be multiarch but not necessarily do that in a backward compatible way. i.e. provide multiarch support for a selected few projects (initially). Over time, projects can migrate to the multiarch branch if needed - the current branch stays on x86_64
<angerman>
It *is*. There is no x86_64 hardcoded logic in there. It’s designed from the ground up to be architecture agnostic.
<tdiesler>
This could perhaps reduce functionality that needs to work with arm64
<angerman>
Support for older GHC versions is in there because we support a wider range of GHCs.
<angerman>
We ran into issues with nixpkgs dropping GHCs too fast.
<angerman>
E.g. updating nixpkgs but still needing older GHCs. That’s why Haskell.nix is somewhat orthogonal to nixpkgs.
<tdiesler>
@angerman I'm trying to think practical here. Lets say, we would want to do arm64 on hydra as well. We cannot select everything to achieve that (it seems). So a practical approach could perhaps be to select an initial subset of functionality that is both relevant and can work on hydra arm64
__monty__ has joined #haskell.nix
<angerman>
tdiesler: here’s the kicker. It *did* work on AArch64 a while ago. Something in either nix, nixpkgs or Haskell.nix recently broke it.
<tdiesler>
@angerman waiting for a fix in nix may not be the best/only option
<tdiesler>
Ah, that's interesting
<tdiesler>
Still, reducing the (functional) load that comes from haskell.nix may be a viable path to move forward
__monty__ has quit [Ping timeout: 256 seconds]
aveltras has joined #haskell.nix
<angerman>
If you find something to reduce Haskell.nixs.complexity without compromising its functionality I’m cartailn we’ll merge it. Yes
<angerman>
I also disagree on fixing nix not being the option. Fixing nix is the *only* option to make nix better.
<angerman>
A lot of things are what they are because I’d limitations of nix.