On May 29, 2010, at 5:39 PM, Marc Weber wrote: > Does it even make sense to ask nix to add -j $NUM_CORES -l $NUM_CORES to > makeFlags if NUM_CORES is > 1 ? > > Then we don't even have to change build scripts. So we don't have to > wait for an stdenv-updates merge to use this new feature.. >
Here's a gentle hint on how to implement NUM_CORES based on hysterical experiences with RPM ... While build "recipes" are just thinly disguised scripts, and make options like -j $NUM_CORES -l $NUM_CORES (and whatever else you wish) can be added explicitly to the commands in the recipe, one should strive to make the gory details of the build "system" as opaque as possible to the build "recipe". There are too many possible policies/heuristics for choosing options passed to make, and there are also too many ways to gain info about the build "system" (like #cpus and loadavg and ...) to expose the details portably. Instead, I'd choose an "opt-in" (or conversely "opt-out") approach as a default rule for invoking make(1) with opaque options that are set from the build "system", not the build "recipe", and then add a means to to deal with "recipes" that do not conform to the general rule. I hope that is what you are attempting to implement. hth 73 de Jeff _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
