Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

[Sam James]

> On 5 Jan 2022, at 19:53, Ulrich Mueller <ulm@g.o> wrote:
>
>>>>>> On Wed, 05 Jan 2022, Florian Schmaus wrote:
>
>>> That applies to all parallel builds though, not only to ebuilds
>>> inheriting check-reqs.eclass. By tweaking MAKEOPTS, we're basically
>>> telling the user that the --jobs setting in their make.conf is wrong,
>>> in the first place.
>
>> Yes, exactly. And it is a bandaid solution. But I believe that it will
>> do more good than evil. And it is probably only used until portage is
>> able to report to the user that the emerge failed due to OOM (which I
>> believe to be non-trivial to implement, but I am happy to be proven
>> otherwise).
>
> Obviously I disagree. Tweaking the value for a subset of packages isn't
> a solution to the problem.
>
> MAKEOPTS applies to all parallel builds, and users should set it to a
> value suitable for their system (i.e. number of CPUs, available memory,
> etc.). Maybe our documentation needs to be improved? I see that
> make.conf.example says "The suggested number for parallel makes is
> CPUs+1" which may not be the best possible advice.
>

As you've noted, the memory requirements vary per package,
and it was somewhat of an oversight/error to not include
the memory limit from the eclass variable instead here
(although I recall kind of deciding to go with this approach
for simplicity).

It's therefore nontrivial to come up with a good value for their
whole system :)

Our documentation has mostly been updated but apparently
make.conf.example hasn't been.