On 12/05/2024 20.21, Michał Górny wrote:
On Sun, 2024-05-12 at 19:22 +0200, Florian Schmaus wrote:On 12/05/2024 04.26, Michał Górny wrote:+ if [[ ${PKGBUMPING} != ${PVR} ]]; then + pushd "${DISTDIR}" >/dev/null || die + + ebegin "Unpacking crates" + printf '%s\0' "${crates[@]}" | + xargs -0 -P "$(makeopts_jobs)" -n 1 -- \Consider using get_makeopts_jobs instead of makeopts_jobs, as it searches more variables for --jobs.
I'm sorry, I was wrong.I thought I remembered that we only extended the new get_makeopts_* functions so that they also search other relevant variables besides MAKEOPTS for --jobs/--load-avgerage. This is wrong, the already existing makeopts_* functions were also changed at that time so that they take GNUMAKEFLAGS & Co. into account.
As a reminder, this change was due to newer Portage versions setting reasonable default values for --jobs and --load-average. And GNUMAKEFLAGS is used for --load-average.
The problem is that the order of the parameters of the makeopts_* functions is unfavorable. First comes the (optional) opts/flags string, then the (optional) default value. This means that as soon as you want to specify the default value explicitly, you also have to specify the opts/flags string. As a result, it can easily happen that only $MAKEOPTS is specified, which can lead to the default value set by portage not being taken into account, especially --load-average. This is, for example, the case with app-i18n/mozc and dev-qt/qtwebengine.
The get_makeopts_* functions do not suffer from this issue. > My suggestion would be for the person who introduced new methods > and implicitly claimed the old methods to be "legacy" to put an actual > effort to migrate consumers. That is probably sensible and I believe also possible.I could only find a single ebuild where makeopts_ was used with a custom make opts/flags string: sci-libs/vtk which has some logic for NINJAOPTS.
However, I wonder if it is ever sensible to specify other make opts/flags besides what _get_all_makeopts() from multiprocessing.eclass considers.
If your make.conf contains NINJAOPS="-j 4 -l 4 <some-ninja-specific-args>" then you most likely always also want to set MAKEOPTS="-j 4" otherwise, only ninja builds are done with "-j 4".Of course, we could also simply add $NINJAOPTS to _get_all_makeopts(). Consequentially this raises the question if other similar variables should also be added (SAMUFLAGS, maybe?).
I'd love to hear some opinions on this. - Flow
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
