> On 5 Jan 2022, at 19:53, Ulrich Mueller <u...@gentoo.org> 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.
signature.asc
Description: Message signed with OpenPGP
