On 23 Nov 2014 21:49, "Ludovic Courtès" <l...@gnu.org> wrote: > > Deck Pickard <deck.r.pick...@gmail.com> skribis: > > > From 8e297904d80b39cd510ba0cced37acdb9b1aeb89 Mon Sep 17 00:00:00 2001 > > From: nebuli <nebu@kipple> > > Date: Sat, 22 Nov 2014 19:58:24 +0100 > > Subject: [PATCH 2/4] guix build: Add --max-jobs option (without handling > > code). > > > > * doc/guix.texi: Mention in the docs. > > * guix/scripts/build.scm: Extend (show-build-options-help) and > > (%standard-build-options) functions. > > Actually I had overlooked that this patch does nothing. :-) > > Could you send an updated version that passes the right option to > ‘set-build-options’? >
No. Using '-c 0 -M 0' fails with cryptic message. On a four core system "innocent" (and logically consistent, I mean, from the description of those options, one expects the daemon to do some load balancing) '-c 4 -M 4' ends up with the same annoying N^2 behaviour. As it is now, not using one of the options leads to sub-optimal saturation of the through-output by default. Not very impressive, if you want to attract hackers who are willing to spend their time and resources to actually build locally from source. After all it's the only way to test and find possible bugs on a wide set of possible configurations. If you want it right, either fix it yourself (and please think hard and carefully what to put in '-from-commandline' function if you want to expose both options to the user) or stop with the antics and apply the patch. I can live with constant branch rebasing, but will end users appreciate their machines locking up? I mean every "proper" Linux user is expected to tail their logs... Unimpressed, drp -- .sig place holder
