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