Gentoo Archives: gentoo-project

From: Samuli Suominen <ssuominen@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Re: Call for agenda items -- Council meeting 2012-06-12
Date: Sun, 03 Jun 2012 12:03:48
In Reply to: Re: [gentoo-project] Re: Call for agenda items -- Council meeting 2012-06-12 by Markos Chandras
On 06/03/2012 11:18 AM, Markos Chandras wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 06/03/2012 04:26 AM, Samuli Suominen wrote: >> On 06/03/2012 06:20 AM, Samuli Suominen wrote: >>> On 06/03/2012 03:01 AM, Ulrich Mueller wrote: >>>>>>>>> On Sun, 03 Jun 2012, Samuli Suominen wrote: >>>> >>>>>> On 05/29/2012 10:09 AM, Fabian Groffen wrote: >>>>> >>>>> >>>>> >>>> >>>>>> >>>>> > Can you indicate what the council has to vote on/decide for this one? >>>> >>>>> EAPI=5 >>>> >>>>> optional: "$@" placement in default for src_configure() >>>> >>>>> econf "$@" >>>> >>>>> optional: "$@" placement in default for src_compile() >>>> >>>>> emake "$@" >>>> >>>> I still don't see the point of it. econf or emake could just be >>>> called directly. We won't gain anything by allowing arguments, >>>> but only complicate things. >>>> >>>>> this one is what I'm really after for: >>>> >>>>> default for src_install() in EAPI=5 should accept "$@" in >>>>> correct place to avoid usage of EXTRA_EMAKE within >>>>> ebuilds/eclasses and to avoid duplicating the Portage code >>>>> for DOCS. NOTE: When this was last voted on for EAPI=3, we >>>>> didn't have this DOCS handling, and this wasn't important >>>>> yet. >>>> >>>>> emake DESTDIR="${D}" "$@" install >>>> >>>> Again, this could be called directly, which has the advantage >>>> that it makes it obvious that src_install isn't the default. >>> >>> The difference is working the tree when you have to alter ebuilds >>> which have been written like: >>> >>> DOCS=( AUTHORS README.NOW "${FILESDIR}"/README.Gentoo ) >>> >>> src_install() { default >>> >>> echo "Some command here." } >>> >>> At this point you have to move content of DOCS which may or may >>> not rely on the ""quoting with array"". Remove the call to >>> default. And then duplicate the EAPI=4 default into the ebuild. >>> >>> And then replicate that every month dozen times and keep on doing >>> it for some months. Get frustrated. >>> >>> If that's not enough, then you get all excited about EAPI=4 and >>> finally think you have a replacement for base.eclass to port >>> xfconf.eclass away from the thing when you only used it for >>> default src_install() to avoid code duplication... >>> >>> Think you are all done, and then get complainment that support >>> for extra arguments for xfconf_src_install was killed, and was >>> required for things like: >>> >>> xfconf_src_install htmldirectory=/usr/share/doc/${PF}/html >>> imagesdir=/usr/share/doc/${PF}/html/images >>> >>> Where sedding the build system runs maintainer mode at .in level, >>> and runnning autotools (.am level) requires heavy documentation >>> dependencies. You go back to base.eclass and get frustrated >>> more. >>> >>> I hope that clears things up ;-) >>> >> >> Also, if not implemented, what is the replacement for EXTRA_EMAKE >> which we are allowed to use from ebuilds? Or are we allowed to use >> it? I think PMS didn't forbid it the last time I checked and it has >> consumers in tree already. >> >> And if not implemented, would the council please vote on banning >> the usage of `default` in src_install() directly from ebuilds? The >> syntax back and forth converting MUST stop. >> >> - Samuli >> > What is the problem with "default" in src_install?
Did you not read the mail at all? The lack of support for arguments makes it useless, and even harmful/annoying when you have to convert them constantly around the tree -Samuli