Don't Nix builds all happen in a randomly generated temporary directory by
default? Then you just copy to $out in installPhase. Perhaps stabilizing
the build directory would help alleviate some of the immediate problems, if
what Joachim is describing affects us too.
On Mon, May 18, 2015 at 10:13 PM, Mateusz Kowalczyk wrote: On 05/14/2015 05:43 PM, Joachim Breitner wrote: Hi, Am Sonntag, den 10.05.2015, 19:39 +0100 schrieb Mateusz Kowalczyk: I'd like to bring some attention to ticket #4012 about non-determinism.
As many of you may know, the nix package manager distributes binaries
throughout its binary caches. The binaries are shared as long as the
hash of some of their inputs matches: this means that we can end up with
two of the same hashes of inputs but thanks to #4012 means that the
actual contents can differ. You end up with machines with some packages
built locally and some elsewhere and due to non-determinism, the GHC
package IDs don't line up and everything is broken. is NixOS sensitive to changes in the build directory. Debian is, and
since 7.8 the build path creeps into the interface files and affects the
hash: https://bugs.debian.org/785282 But you probably are not, otherwise you’d have complained when 7.8 was
out, and not now :-) Greetings,
Joachim Not a problem for nix, the paths are are calculated based on the
derivation inputs. I don't want to go into details but if same
expression goes in, same path comes out. If the path that comes out is
different, you simply don't get to use it. More or less nix does
‘calculate the store path from this expression, check if it exists in
binary caches and fetch it if it does, build if it does not’. So for us the store paths in the interface files would always be the
same for the same inputs hence no problem there. --
Mateusz K.
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs