The ebuild doesn't have a fixed RAM requirements (iherit check-reqs, CHECKREQS_MEMORY). instead, it takes makeopts_jobs parameter and multiples it. In my case, I have -j12, which converts into "24 GiB RAM" but I only have 16 Gib. It gave me a wrong impression that I need to upgrade RAM (which I can't). However, a "workaround" is just to decrease the value to "-j8". Please find a better solution.
It's always going to be an imperfect estimation. There is no "good" solution there.
(In reply to Mike Gilbert from comment #1) > It's always going to be an imperfect estimation. There is no "good" solution > there. hm... is it possible to do the other way around? Check available RAM, calculate -j value and notify user if his current setting is too high?..
(In reply to Anton Bolshakov from comment #0) > It gave me a wrong impression that I need to upgrade RAM (which I can't). > However, a "workaround" is just to decrease the value to "-j8". So you mean the issue is that it's unclear that you need to reduce -jN rather than the estimation potentially being wrong? But given basing this -jN is done in most ebuilds (bare those that have a single job that consume high memory), the eclass already tells you about reducing MAKEOPTS (or add swap as alternative). e.g. with MAKEOPTS=-j128 (what could go wrong): * There is NOT at least 256 GiB RAM * * Memory or space constraints set in the ebuild were not met! * The build will most probably fail, you should: * - enhance the memory (reduce MAKEOPTS, add swap), or * - add more space * as required depending on the failed tests. Wording could likely be better (feel free to file a bug against check-reqs.eclass and/or do a PR if you feel that should be improved), but I don't think there's anything that the qtwebengine ebuild needs to do differently in that regard. At best could add a einfo to inform that we're estimating based on -jN, but that's likely to go missed anyway given it won't be shown in the error that the eclass emits and then abort after -- and unconditional ewarn/elog would be noisy for nothing.
I mproved the error in commit e105854611974017415af6199d521b78f1134ff4 Author: Sam James <sam@gentoo.org> Date: Tue Aug 22 18:11:34 2023 +0100 check-reqs.eclass: clarify failed requirements error Explicitly suggest lower MAKEOPTS jobs and/or adding swap for bad RAM amount. Signed-off-by: Sam James <sam@gentoo.org> which I think is indeed the best we can do here.
(In reply to Sam James from comment #4) > Improved the error in [...] Ah ok, thought this was always there which had me wondering for this bug. Guess understandable was confused then.
