Hello! Eelco Dolstra <[email protected]> writes:
> I used to be against this because the purity risk, but if it's turned *on* on > a > per-package basis, it's probably an acceptable risk. (We also have a stack of > 8-core machines here that we should put to good use ;-) I used to be in favor of something like that but... It's very hard to check whether a package is parallel-build-safe. You'd have to, e.g., build it tens of times and if the output is the same for all builds, you'd get *some* confidence. > PS: I have this wild idea of making a front end for Nix that reads a Makefile > and basically converts it to a Nix expression - that is, every Make rule > becomes > a derivation. Then you get all the parallelism you want and it would still be > pure. Or conversely, if your Makefile isn't pure (e.g. if build actions > interfere with each other), it would deterministically fail. As an added > bonus, > you would never have to write another "make clean" rule :-) Incidentally, there was once work about non-timestamp-based dependencies in GNU Make, which would allow the use of crytographic hashes to determine whether a target is up-to-date: http://lists.gnu.org/archive/html/make-alpha/2007-10/msg00007.html http://lists.gnu.org/archive/html/make-alpha/2007-04/msg00008.html That was apparently never integrated, though. Thanks, Ludo'. _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
