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 _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
