On 05/01/2022 19.22, Ulrich Mueller wrote:
On Wed, 05 Jan 2022, Florian Schmaus wrote:
On 05/01/2022 09.28, Ulrich Mueller wrote:
On Tue, 04 Jan 2022, Sam James wrote:
Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the
amount of RAM available (uses amount declared as needed
in the ebuild). Typically should be ~2GB per job.
Where does this number 2 GB come from? The amount of RAM strongly
depends on the programming language and other factors, so I don't
believe that there's one number that can be used for everything.
Surely not, but 2 GiB seems like a good start. I guess it could become
an eclass variable that ebuilds could modify later (if the need
emerges).
We already have an eclass variable, namely CHECKREQS_MEMORY. Do you want
to introduce another one that is counting memory per job? I doubt that
would be possible, because the amount of memory greatly varies within a
single build. For example, it is different for compiler vs linker vs
building the documentation.
I am not sure what the problem here supposed to be is.
It appears to me that the motivation for this change is to prevent
users from running into OOM situations when emerging a package. And I
believe that many users, especially novices, are not directly able to
determine that portage failed due to OOM, simply because there is no
direct hint in the build log. Hence opt-out appears to be sensible to
me here.
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).
- Flow
