Peter Simons wrote:
Hi Marc,
the ability to utilize multi-processor machines is highly desirable.
Thank you for writing a patch that goes into this direction.
I wonder, though, whether the approach of hard-coding know-how about the
$NUM_CORES variable into Nix itself is the way to go. IMHO, a more
general mechanism is required, namely the ability to pass variables to
an expression that do not modify the hash. $NUM_CORES is just one
example of such a variable. Another one is $doCheck. Some sites might
want to enable "make check" by default, others might not. In the general
case it's not obvious why a "make check"ed version of a given package
should have a different $out path than one that hasn't been checked.
why, are you saying that testing should ever change the installed
program? If we don't want this, can't we install (or archive) before
running the tests? so the only thing we base on the build-directory
after running the tests, is whether the tests succeeded?(or are some
test-systems more intrusive than this?) But I'm sure there will be
other examples that shouldn't modify the hash too, but have the
potential to, also like multi-core. Of course, each such thing that
could change the result should probably be judged harshly to see if it's
really worth the risk for many people :-)
If we're using the model where derivations are defined to produce a set
of possible results that are functionally equivalent (because we can't
always force everything about the build process to be deterministic in
result-bytes), then it doesn't necessarily make sense to say "doesn't
change the hash" rather than "doesn't make the behavior vary any more
than it does between compiles without any build-modifications"?
-Isaac
_______________________________________________
nix-dev mailing list
[email protected]
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
