>>>>> 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. > 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. Ulrich
signature.asc
Description: PGP signature
