[Nix-dev] Re: Another approach at parallelizing in-build jobs

[Jeff Johnson]

On Jun 20, 2010, at 6:05 PM, Nicolas Pierron wrote:

> Hi,
> 
> On Sun, Jun 20, 2010 at 22:23, Jeff Johnson <n3npq at mac.com> wrote:
>> 
>> On Jun 20, 2010, at 4:02 PM, Peter Simons wrote:
>> 
>>> 
>>> In other words, should a glibc that's been built with -j1 have a store
>>> path different from one that's been built with -j2?
>>> 
>> 
>> Since every build has different store path, does your question even make sense?
> 
> The output path hash is computed before the first step of the
> compilation by combining all its dependencies and it build script and
> other stuff used to define the build process.  The hidden question
> that is asked here is should we consider -j options as a build
> modifier or as a no-op option, in other words should we consider it in
> the hash computation?
> 
> IMO, this depends on our ability at tagging builds with it.  So we
> should probably have both method like:
> * safe -j* builds in which case this is considered as a no-op.
> (unlikely packages made with more than one make instances)
> * unsafe -j* builds in which case this is considered as an unsafe operation.
> 
> The unsafe build could be used as a fallback if the safe build is not
> provided by any other repositories or manifest.
> 

OK, so the question is meaningful.

Does the output path hash take into how many CPU's are present?
How many CPU's are online? How many other computations are
currently running? Whether there's an ECC error in memory
at the time of the build?

All of the above will affect "make -jN" behavior even if you
decide to include "make -jN" as part of the output hash computation.

So you might as well just ignore "-jN" imho.

Or do I still miss something?

73 de Jeff