From: Florian Schmaus <flow@gentoo.org>
To: gentoo-dev@lists.gentoo.org, "Michał Górny" <mgorny@gentoo.org>
Subject: [gentoo-dev] Obtaining values for --jobs and --load-average
Date: Thu, 16 May 2024 08:55:40 +0200 [thread overview]
Message-ID: <30d8d115-579a-4cba-9bb3-64e4b787a153@gentoo.org> (raw)
In-Reply-To: <849a540bd028ac0fed47c75c71ecf077f703c28d.camel@gentoo.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 2626 bytes --]
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
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 17797 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]
prev parent reply other threads:[~2024-05-16 6:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-12 2:26 [gentoo-dev] [PATCH] cargo.eclass: Optimize crate unpacking Michał Górny
2024-05-12 2:44 ` Sam James
2024-05-12 17:22 ` Florian Schmaus
2024-05-12 18:21 ` Michał Górny
2024-05-13 14:00 ` Florian Schmaus
2024-05-13 14:02 ` Michał Górny
2024-05-16 6:55 ` Florian Schmaus [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=30d8d115-579a-4cba-9bb3-64e4b787a153@gentoo.org \
--to=flow@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=mgorny@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox