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.
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'.
(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.
makes sense to me
The Council voted against the DEFAULT_ variables last time around...
these arent DEFAULT_ variables
(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.
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.
(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...
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.
Like, src_configure() -> default "$@" -> econf "$@" src_compile() -> default "$@" -> emake "$@" src_install() -> default "$@" -> emake "$@"
(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.
(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
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.
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
EXTRA_* isn't in the spec.
(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'.
(Bug 459692 comment #4:) > bug 364343 can be closed with wontfix then, imho
