Re: [PATCH] Hotfix (repeat)

[Deck Pickard <deck.r.pickard@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

On 23 Nov 2014 21:49, "Ludovic Courtès" <ludo@gnu.org> wrote:
>
> Deck Pickard <deck.r.pickard@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

[-- Attachment #2: Type: text/html, Size: 2159 bytes --]