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

[Isaac Dupree]

Peter Simons wrote:
>  > 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"?
> 
> I am sorry, but I don't understand the meaning of this paragraph. Can
> you please re-iterate this point?

oh, sorry.  My understanding was that derivations are already not all 
deterministic.  That is, (for some packages), given the same source code 
and builder, the build process might produce one output (hash) one day 
and a different one the next time you try it.

If that understanding is true, then it's not necessarily clear what the 
meaning is of a statement that a modification such as NUM_CORES "doesn't 
change the hash". -- because "the hash" wasn't even well-defined before 
the addition of NUM_CORES.

This is based on the discussion of "equivalence classes" in 
dolstra-thesis.pdf, section 6.4 "Semantics".  ( which I apparently 
downloaded from http://grosskurth.ca/bib/2006/dolstra-thesis.pdf ).  I'm 
not sure how valid its pessimism about determinism is in most cases though.

-Isaac