[Nix-dev] Re: experimental -J NUM_CORES option patch / looking for reviews

[Isaac Dupree]

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