| Summary: | MAKEOPTS should always be set | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Christoph Junghans (RETIRED) <junghans> |
| Component: | Documentation | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | pms |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=490754 https://bugs.gentoo.org/show_bug.cgi?id=250122 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Christoph Junghans (RETIRED)
2013-11-23 19:34:55 UTC
PMS mentions MAKEOPTS only once:
> emake Calls the $MAKE program, or GNU make if the MAKE variable
> is unset. Any arguments given are passed directly to the make
> command, as are the user’s chosen MAKEOPTS.
I'd say that you aren't supposed to modify this in ebuild, and more specifically you aren't allowed to rely on any specific magic in it.
Doesn't this just behave like any other variable from make.conf? Most of them are optional. If you want to ensure that it is in the environment (and it should be there, because emake is an external shell script) then the ebuild must export it. (In reply to Michał Górny from comment #1) > PMS mentions MAKEOPTS only once: > > > emake Calls the $MAKE program, or GNU make if the MAKE variable > > is unset. Any arguments given are passed directly to the make > > command, as are the user’s chosen MAKEOPTS. > > I'd say that you aren't supposed to modify this in ebuild, [...] Not sure. How is this different from CFLAGS which is regularly modified (e.g. in flag-o-matic.eclass)? I got a bit confused by the statement in the ebuild 5 man page: Performs 'make ${MAKEOPTS} make options' (as set in make.globals), default is MAKEOPTS="-j2".
It might be an idea to remove things that are controlled by the spec from the Portage man pages to avoid confusion. (In reply to Ciaran McCreesh from comment #4) i don't think that'd be an improvement Nothing to fix in PMS, it seems. Feel free to reopen if you disagree. If we don't want to set MAKEOPTS by default due to PMS, we should at least make portage's man page more clear.
And we need to fix the following ebuilds:
$ find /usr/portage -name "*.ebuild" -exec grep -E '^MAKEOPTS\+?=' {} + | grep -v -- "-j1"
/usr/portage/app-admin/sudo/sudo-1.8.8.ebuild:MAKEOPTS+=" SAMPLES="
/usr/portage/app-admin/sudo/sudo-1.8.6_p8.ebuild:MAKEOPTS+=" SAMPLES="
/usr/portage/app-admin/sudo/sudo-1.8.6_p7.ebuild:MAKEOPTS+=" SAMPLES="
/usr/portage/app-admin/sudo/sudo-1.8.5_p2.ebuild:MAKEOPTS+=" SAMPLES="
/usr/portage/app-emulation/simh/simh-3.3.0.ebuild:MAKEOPTS="USE_NETWORK=1 ${MAKEOPTS}"
/usr/portage/app-emulation/simh/simh-3.8.1.ebuild:MAKEOPTS="USE_NETWORK=1 ${MAKEOPTS}"
/usr/portage/sci-visualization/gwyddion/gwyddion-2.30-r1.ebuild:MAKEOPTS+=" V=1"
/usr/portage/sci-visualization/gwyddion/gwyddion-2.30.ebuild:MAKEOPTS+=" V=1"
/usr/portage/sci-visualization/gwyddion/gwyddion-2.29.ebuild:MAKEOPTS+=" V=1"
/usr/portage/app-text/build-docbook-catalog/build-docbook-catalog-1.20.ebuild:MAKEOPTS+=" EPREFIX=${EPREFIX}"
However adding MAKEOPTS="" to make.globals might be easier.
(In reply to Christoph Junghans from comment #7) > If we don't want to set MAKEOPTS by default due to PMS, we should at least > make portage's man page more clear. Reassigning. > However adding MAKEOPTS="" to make.globals might be easier. Ebuilds shouldn't rely on it and should therefore be fixed in any case. (In reply to Ulrich Müller from comment #8) > (In reply to Christoph Junghans from comment #7) > > However adding MAKEOPTS="" to make.globals might be easier. > Ebuilds shouldn't rely on it and should therefore be fixed in any case. Ok, should we change "MAKEOPTS\+?=..." to "export MAKEOPTS\+?=..." ? And a repoman check might be good as well. (In reply to Christoph Junghans from comment #9) > (In reply to Ulrich Müller from comment #8) > > (In reply to Christoph Junghans from comment #7) > > > However adding MAKEOPTS="" to make.globals might be easier. > > Ebuilds shouldn't rely on it and should therefore be fixed in any case. > Ok, should we change "MAKEOPTS\+?=..." to "export MAKEOPTS\+?=..." ? How about: emake ... ? This one's guaranteed to work, unlike the other lazy hackery. (In reply to Michał Górny from comment #10) > (In reply to Christoph Junghans from comment #9) > > (In reply to Ulrich Müller from comment #8) > > > (In reply to Christoph Junghans from comment #7) > > > > However adding MAKEOPTS="" to make.globals might be easier. > > > Ebuilds shouldn't rely on it and should therefore be fixed in any case. > > Ok, should we change "MAKEOPTS\+?=..." to "export MAKEOPTS\+?=..." ? > How about: > emake ... > ? This one's guaranteed to work, unlike the other lazy hackery. That would mean every emake call needs to be explicitly and default functions cannot be used automatically. How about adding a function like append_to_makeopts to flag-o-matic.eclass? Which could be triggered automatically in pkg_setup if EXTRA_MAKEOPTS is set in the ebuild. (In reply to Christoph Junghans from comment #11) > (In reply to Michał Górny from comment #10) > > How about: > > emake ... > > ? This one's guaranteed to work, unlike the other lazy hackery. > That would mean every emake call needs to be explicitly and default > functions cannot be used automatically. > > How about adding a function like append_to_makeopts to flag-o-matic.eclass? > Which could be triggered automatically in pkg_setup if EXTRA_MAKEOPTS is set > in the ebuild. Yes, that's the intent with defaults. Defaults are for default cases. If you want something custom (and passing custom arguments to make is *custom*) you write your own phases. I can't find it right now but the Council has already stated that they dislike defaults accepting explicit or implicit arguments. The wording in the man page has changed since this. If you still feel there is an issue, please point to the specific objection you have with the manpage, and if possible suggest a suitable improvement. (In reply to Alexander Berntsen from comment #13) > The wording in the man page has changed since this. If you still feel there > is an issue, please point to the specific objection you have with the > manpage, and if possible suggest a suitable improvement. I am not sure what the manpage has to do with the original issue. The original problem was that using "MAKEOPTS+=XXX" in an ebuild is bad due to the fact if MAKEOPTS are not set in the ebuild environment (by the profile or user) adding something to it outside the phase function (global context) has no effect. However, this issue only appears in profiles where MAKEOPTS has no default, which isn't the case anymore with recent portage version see: <https://gitweb.gentoo.org/proj/portage.git/commit/?id=5a1e6c9710becab384b684ad6ba55e025d63a60e> Thanks Michał for fixing that! (In reply to Christoph Junghans from comment #14) > I am not sure what the manpage has to do with the original issue. See comments #3, #7, & #8. > The original problem was that using "MAKEOPTS+=XXX" in an ebuild is bad due > to the fact > if MAKEOPTS are not set in the ebuild environment (by the profile or user) > adding something to it outside the phase function (global context) has no > effect. The bug was changed and reassigned, see comments referenced above. Either way it's resolved now. |
