Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 364343 - sys-apps/portage: EXTRA_EMAKE should be split into another variable to separate the ones set by an user, and the ones set by an ebuild
Summary: sys-apps/portage: EXTRA_EMAKE should be split into another variable to separa...
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: future-eapi
  Show dependency tree
 
Reported: 2011-04-21 12:42 UTC by Samuli Suominen
Modified: 2013-03-21 09:52 UTC (History)
3 users (show)

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


Attachments
Example version bump of ImageMagick (use-case-example.txt,2.00 KB, text/plain)
2012-05-10 14:09 UTC, Samuli Suominen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Samuli Suominen gentoo-dev 2011-04-21 12:42:14 UTC
Right now `default` for src_install introduced by EAPI=4 doesn't accept args.   

It's like:

emake DESTDIR="${D}" install

Where it should be:

emake DESTDIR="${D}" "$@" install

So people can call simply:

src_install() {
  default HTMLDIR=/path/to/html IMAGESDIR=/path/to/html/images
}

This would be useful for us in xfconf.eclass, where we need both the emake install and DOCS both as an DOCS="" for migration and DOCS=( ) and don't want to duplicate the Portage's code just to append flags.

I guess `EXTRA_EMAKE="$@ ${EXTRA_EMAKE}" default` isn't acceptable, right? I'm kind of opting to use it in the xfconf.eclass until this bug is solved.
Comment 1 Ciaran McCreesh 2011-04-21 13:59:13 UTC
That really runs against how phase functions work. Phase functions don't accept arguments.

If your code isn't the 'default', don't use 'default'.
Comment 2 Samuli Suominen gentoo-dev 2011-04-27 07:39:21 UTC
(In reply to comment #1)
> That really runs against how phase functions work. Phase functions don't accept
> arguments.

Why not make them accept?

> 
> If your code isn't the 'default', don't use 'default'.

As I said, I don't feel like duplicating code that already exists and do it dozens of times around the tree.
Comment 3 SpanKY gentoo-dev 2011-04-30 03:03:25 UTC
makes sense to me
Comment 4 Ciaran McCreesh 2011-04-30 10:01:11 UTC
The Council voted against the DEFAULT_ variables last time around...
Comment 5 SpanKY gentoo-dev 2011-05-01 22:42:08 UTC
these arent DEFAULT_ variables
Comment 6 Brian Harring gentoo-dev 2011-05-02 01:01:55 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > That really runs against how phase functions work. Phase functions don't accept
> > arguments.
> 
> Why not make them accept?
Provide examples where it makes sense, and a clear statement of how it actually would work.  Your examples wouldn't do anything, for example.

As for making them accept, it's not happening in EAPI4 (retroactive like this doesn't fly at all)...

@spanky:
Strongly suspect going by xfconf, these actually /are/ DEFAULT_* vars- seems to be the only thing being done there is extending a couple of lists/args in use.
Comment 7 SpanKY gentoo-dev 2011-05-02 01:17:51 UTC
he already provided an example, and he isnt requesting support for DEFAULT_xxx in the spec (which is what the council votes on).  so the behavior of random eclasses wrt DEFAULT_xxx vars is irrelevant.
Comment 8 Brian Harring gentoo-dev 2011-05-02 01:53:10 UTC
(In reply to comment #7)
> he already provided an example,
brainfart; missed that those var's were intended to be fed down through emake itself.

> and he isnt requesting support for DEFAULT_xxx
> in the spec (which is what the council votes on).
DEFAULT_* accomplishes similar.  To be clear, what is being requested, while not explicitly forbidden by PMS, is pretty clearly breaking compatibility (it's not a tweak/addition that has zero harm if unsupported, as such it's a retroactive change).  Doesn't violate the words of the spec, but clearly the spirit...

> so the behavior of random
> eclasses wrt DEFAULT_xxx vars is irrelevant.
Ciaran's referring to DEFAULT_* vars that the normal/default eapi implementations would consume.  EXTRA_EMAKE for example; at least that's how I interpreted it, and it would cover the original request...
Comment 9 Samuli Suominen gentoo-dev 2012-05-10 14:09:32 UTC
Created attachment 311355 [details]
Example version bump of ImageMagick

Can we get the "$@" added to phases so we can avoid this? I keep hitting this like 2-3 per week, seriously.
Comment 10 Samuli Suominen gentoo-dev 2012-05-10 14:11:32 UTC
Like,

src_configure() -> default "$@" -> econf "$@"
src_compile() -> default "$@" -> emake "$@"
src_install() -> default "$@" -> emake "$@"
Comment 11 Ulrich Müller gentoo-dev 2012-05-10 14:31:40 UTC
(In reply to comment #10)
> src_configure() -> default "$@" -> econf "$@"
> src_compile() -> default "$@" -> emake "$@"

What would be the advantage of using the first commands instead of the second ones?

> src_install() -> default "$@" -> emake "$@"

Instead of the default emake arguments, or in addition to them? I find this one rather obscure. IMHO, if you need extra arguments, then it's not the default any more and should be written in explicit form.
Comment 12 Samuli Suominen gentoo-dev 2012-05-12 16:46:07 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > src_configure() -> default "$@" -> econf "$@"
> > src_compile() -> default "$@" -> emake "$@"
> 
> What would be the advantage of using the first commands instead of the
> second ones?

- For consistency if this is going to get added to src_install()
- This way you can state you want the default, which is moving target, and things might get added or removed from it per EAPI

> 
> > src_install() -> default "$@" -> emake "$@"
> 
> Instead of the default emake arguments, or in addition to them? I find this
> one rather obscure. IMHO

In addition to the defaults, passed after the defaults so overriding is left possible
Comment 13 Samuli Suominen gentoo-dev 2012-06-16 11:57:27 UTC
The council voted against allowing $@ arguments for `default` in phases here:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20120612-summary.txt

So we are stuck with using EXTRA_ECONF and EXTRA_EMAKE from ebuilds for now. I'll convert this to an request of creating extra variables that get passed along then, like, for example, EXTRA_EMAKE_INSTALL to make my point.
Comment 14 Samuli Suominen gentoo-dev 2012-06-16 12:01:48 UTC
python.eclass, EXTRA_EMAKE
bsdmk.eclass, EXTRA_EMAKE
toolchain.eclass, EXTRA_ECONF
toolchain-binutils.eclass, EXTRA_ECONF
ruby.eclass, EXTRA_ECONF
+ few more and couple of dozen consumers ebuild wise currently
Comment 15 Ciaran McCreesh 2012-06-16 12:20:28 UTC
EXTRA_* isn't in the spec.
Comment 16 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2012-06-16 12:36:58 UTC
(In reply to comment #13)
> The council voted against allowing $@ arguments for `default` in phases here:
> 
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/
> council/meeting-logs/20120612-summary.txt
> 
> So we are stuck with using EXTRA_ECONF and EXTRA_EMAKE from ebuilds for now.
> I'll convert this to an request of creating extra variables that get passed
> along then, like, for example, EXTRA_EMAKE_INSTALL to make my point.

'The council voted against it, so we're going to put it through anyway, under different name'.
Comment 17 Ulrich Müller gentoo-dev 2013-03-21 09:52:37 UTC
(Bug 459692 comment #4:)
> bug 364343 can be closed with wontfix then, imho