Make cross-compilation work again. #4881
Conversation
To correctly eval the haskell.nix project we need the pkgs for the current system, not the cross system one. cf. input-output-hk/haskell.nix#1666
| @@ -20,6 +20,7 @@ let | |||
| r-packages = with rPackages; [ R tidyverse dplyr stringr MASS plotly shiny shinyjs purrr ]; | |||
| project = haskell-nix.cabalProject' ({ pkgs, ... }: { | |||
| inherit compiler-nix-name; | |||
| evalPackages = pkgs.buildPackages.buildPackages; | |||
There was a problem hiding this comment.
comment, please! Also I don't think we want this: this makes it not possible to evaluate things on a different system from the build one, which we used to be able to do. So should we not actually use evalPackages here?
There was a problem hiding this comment.
Indeed, isn't that the default? or is the issue that the default is broken?
There was a problem hiding this comment.
evalPackages default is pkgs.buildPackages. But apparently this not enough, probably because:
nix eval -f ./default.nix --arg crossSystem '{ config = "x86_64-w64-mingw32"; libc = "msvcrt"; }' plutus.haskell.project.pkgs.buildPackages.targetPlatform.system
"x86_64-windows"
while with pkgs.buildPackages.buildPackages
nix eval -f ./default.nix --arg crossSystem '{ config = "x86_64-w64-mingw32"; libc = "msvcrt"; }' plutus.haskell.project.pkgs.buildPackages.buildPackages.targetPlatform.system
"x86_64-linux"
But not sure why exactly. Maybe @hamishmack ?
There was a problem hiding this comment.
Oh that is a good point. Just using .buildPackages has caused problems in the past with caching. IIRC anything that used python (including some surprising things like git) would include a dependency on gdb (I think it was gdb), but buildPackages.gdb would be the cross compiler gdb (not the native one). The result was that git would recompile.
There was a problem hiding this comment.
|
Thanks for the fix! |
| @@ -22,6 +22,8 @@ let | |||
|
|
|||
| compiler-nix-name = library.ghc-compiler-nix-name; | |||
|
|
|||
| evalPackages = library.pkgs; | |||
There was a problem hiding this comment.
Should this not also use library.pkgs.buildPackages.buildPackages?
There was a problem hiding this comment.
no, in this case library.pkgs is the original pkgs (not from any cross* invocation), so the one we want.
There was a problem hiding this comment.
That doesn't make sense to me, aren't these two files literally the same thing just with one of them setup for the new infra? how are we doing cross builds in the std world then?
There was a problem hiding this comment.
with plutus-project.projectCross.mingwW64.
There was a problem hiding this comment.
More attributes over functions :( What was wrong with the old way? I won't fight about it though.
There was a problem hiding this comment.
though, using pkgs.pkgsBuildBuild should also work and must be the same. so we can use it instead of library.pkgs.
There was a problem hiding this comment.
I'm very pro consistency if it doesn't cost us anything!!
There was a problem hiding this comment.
There was a problem hiding this comment.
thanks. I'll close this PR then.
|
Also, I remembered that there's a simpler and clearer way to get this: |
|
upstreamed in input-output-hk/haskell.nix#1739 |
To correctly eval the haskell.nix project we need the pkgs for the current
system, not the cross system one.
cf. input-output-hk/haskell.nix#1666
Issue was introduced with haskell.nix bump in in #4871 (comment)
Related issue is that haskell.nix should not silently ignore dependencies errors:
input-output-hk/haskell.nix#1392