Hamish Mackenzie
Hamish Mackenzie
~~I think this is an `aarch64-darwin` issue. `x86_64-darwin` seems ok.~~ I tried to build ghcjs 8.6.5 on ~~aarch64~~ x86_64-darwin and got: ``` $ nix-build -E '(import ./. {}).pkgs-unstable.pkgsCross.ghcjs.haskell-nix.tool "ghc865" "hello"...
Oh no! That was a x86_64-darwin build (8.6.5 will probably never work on aarch64_darwin).
> For example, I think lib/call-cabal-project-to-nix.nix should be run entirely at eval time, and so should just have a single pkgs: the eval packages. However, it in fact gets passed...
> So how does this work if you eval on a machine with a platform different to the build platform? The output of `ghc` is captured on the build platform...
Everywhere `evalPackages` is used it is now passed in explicitly (there is no `pkgs.evalPackages` that might magically start running stuff on the eval system). I think that probably helps. What...
Maybe we need more low level `isLocal` (one that we could not override) to avoid infinite recursion.
Perhaps we could have `plan-to-nix` and `stack-to-nix` output `localNames` (but not as part of the modules). So in your example instead of: ``` localPkgs = pkgs.lib.filterAttrs (pkg: pkgs.isLocal) options.packages.value; localNames...
First try: ``` pkgSet = pkgs.haskell-nix.mkStackPkgSet { # stack-pkgs = patchCommonPackage (import ./pkgs.nix); stack-pkgs = import ./pkgs.nix; pkg-def-extras = []; modules = [ ({ config, options, hackage, ...}: { config.packages...
``` haskellNix = builtins.fetchTarball "https://github.com/input-output-hk/haskell.nix/archive/f1a94a4c82a2ab999a67c3b84269da78d89f0075.tar.gz"; ``` f1a94a4c82a2ab999a67c3b84269da78d89f0075 is a very old version of haskell.nix. I suspect we might not have updated the commit hash in the docs when the instructions...
Did using a more recent haskell.nix help?