[Nix-dev] Re: [Nix-commits] SVN commit: nix - 22282 - MarcWeber - nixpkgs/branches/stdenv-updates/pkgs/stdenv/generic

Peter Simons simons at cryp.to
Fri Jun 18 13:00:07 CEST 2010


Hi Lluís,

 > 1. Hydra does not need the in-build parallelization, she has enough
 > with the inter-build parallelization

I don't use pre-built binaries from Hydra, I don't feel strongly about this
topic. However, I would really like to see this claim backed up by data. I
very much doubt that Hydra could not benefit from build parallelism.


 > 2. There is no way for nix to manage the balance between in-build and
 > inter-build parallelization (make -j, and nix max-jobs).

I think that this claim is inaccurate. GNU Make's "-l" flag does provide
means for ensuring a sensible system load, and there are other means to
accomplish the same thing.


 > 3. Nix developers, wanting a quick build for testing, can add the "make -j X"
 > temporarily before commiting the expression.

Adding "make -j X" temporarily does not solve the problem that certain
builds take ages (OpenOffice, boost, gcc, qt, firefox etc.) when performed
on a single core.


 > 4. The benefits of your change come at the expense of some clarity in
 > stdenv, and some impurities, and in the nix world many don't like
 > impurities much.

I agree that impurities are undesirable in general. In this particular case,
however, I don't see a problem. Passing the number of available cores to
Make is a fairly insignificant impurity that allows for fairly significant
benefits, i.e. significantly reduced build times.


 > 5. By default, generic builder expressions should not be built parallelizing at
 > all.

Yes, this is true. It was a mistake to implement this patch using an opt-out
scheme. Clearly, opt-in is what we want.


 > I'm for the revert, considering what I wrote above.

I disagree with most of the points you made. However, I am in favor of
reverting the patch, too, because I'm not particularly fond of the
implementation -- especially of the choice to implement opt-out.

Take care,
Peter




More information about the nix-dev mailing list