Re: [gentoo-user] gcc fails and then succeeds - definitely a problem?

[Michael Mol]

On Thu, Feb 23, 2012 at 4:00 PM, Grant <emailgrant@×××××.com> wrote:
>>> > Parallel builds are not deterministic so if the Makefile allows a race
>>> > condition to develop it's pot luck whether you'll be hit with it or
>>> > not
>>>
>>> I got sick of stuff like that so I run MAKEOPTS="-j1" on all of my
>>> systems.
>>
>> If it were a frequent occurrence, there may be some benefit in that. But
>> using only one of the CPUs 8 cores is such a waste when this sort of
>> thing happens only every few weeks. Usually trying again works, rarely
>> does using -j1 make a difference and when it does a bug report ensures
>> that it won't be an issue in future.
>
> OK you've inspired me to give it another try.  So if I find a package
> that doesn't build with -jn where n > 1 but does build with -j1 I
> should file a bug?

Pretty much. It can get more specific than that, but that much is
already a help.

Here's the relevant portions of my MAKEOPTS and EMERGE_DEFAULT_OPTS
which should speed things up for you about as much as possible.

MAKEOPTS="--jobs --load $n" # Where $n is num_CPUs * 1.25
EMERGE_DEFAULT_OPTS="--jobs --load-average=$m" # Where $m is num_CPUs * 1.5

With the "--jobs" parameters, I haven't needed to set $n or $m to
num_CPUS*2 to try to keep the load average up.

Here's my MAKEOPTS and EMERGE_DEFAULT_OPTS verbatim, for an eight-core machine:

MAKEOPTS="--jobs --load 10"
EMERGE_DEFAULT_OPTS="--jobs --load-average=12 --verbose --tree
--with-bdeps=y --keep-going"

If you want to keep things simple, just go with num_CPUs=n for both $m and $n.

-- 
:wq