Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 492372 - MAKEOPTS should always be set
Summary: MAKEOPTS should always be set
Status: RESOLVED OBSOLETE
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Documentation (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-23 19:34 UTC by Christoph Junghans
Modified: 2016-02-02 16:33 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Junghans gentoo-dev 2013-11-23 19:34:55 UTC
If MAKEOPTS are not set in the ebuild environment adding something to it outside the phase function has no effect.

See bug #490754 for an example.

In the most common case, MAKEOPTS="$MAKEOPTS -j1", no problem will appear as no MAKEOPTS has the same effect as -j1. However for cases, like MAKEOPTS+=" V=1", the additional options will not be appended if MAKEOPTS wasn't already set in the environment.

10 ebuilds do something alone these lines:
$ find /usr/portage -name "*.ebuild" -exec grep -E '^MAKEOPTS\+?=' {} + | grep -v -- "-j1" | wc -l
10
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-12-21 17:50:37 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.
Comment 2 Ulrich Müller gentoo-dev 2013-12-21 18:44:12 UTC
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)?
Comment 3 Christoph Junghans gentoo-dev 2013-12-21 19:13:44 UTC
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".
Comment 4 Ciaran McCreesh 2013-12-21 19:30:00 UTC
It might be an idea to remove things that are controlled by the spec from the Portage man pages to avoid confusion.
Comment 5 SpanKY gentoo-dev 2014-01-05 13:53:17 UTC
(In reply to Ciaran McCreesh from comment #4)

i don't think that'd be an improvement
Comment 6 Ulrich Müller gentoo-dev 2014-01-05 20:29:57 UTC
Nothing to fix in PMS, it seems.
Feel free to reopen if you disagree.
Comment 7 Christoph Junghans gentoo-dev 2014-01-05 20:59:32 UTC
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.
Comment 8 Ulrich Müller gentoo-dev 2014-01-05 22:05:26 UTC
(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.
Comment 9 Christoph Junghans gentoo-dev 2014-01-09 05:42:23 UTC
(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.
Comment 10 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-01-09 06:59:42 UTC
(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.
Comment 11 Christoph Junghans gentoo-dev 2014-01-09 15:37:21 UTC
(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.
Comment 12 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-01-09 17:45:01 UTC
(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.
Comment 13 Alexander Berntsen (RETIRED) gentoo-dev 2016-02-02 15:27:52 UTC
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.
Comment 14 Christoph Junghans gentoo-dev 2016-02-02 16:28:05 UTC
(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!
Comment 15 Alexander Berntsen (RETIRED) gentoo-dev 2016-02-02 16:33:59 UTC
(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.