From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LgRIW-0008Jx-3q for garchives@archives.gentoo.org; Sun, 08 Mar 2009 22:16:40 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7B761E0503; Sun, 8 Mar 2009 22:16:38 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 59FA6E0503 for ; Sun, 8 Mar 2009 22:16:38 +0000 (UTC) Received: from gentoo.org (c-98-246-79-112.hsd1.or.comcast.net [98.246.79.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id D7EAC64C79 for ; Sun, 8 Mar 2009 22:16:37 +0000 (UTC) Date: Sun, 8 Mar 2009 15:16:37 -0700 From: Donnie Berkholz To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Ideas for a (fast) EAPI=3 Message-ID: <20090308221637.GP14240@comet> References: <1236498557.6854.51.camel@neuromancer> <20090308164228.GG14240@comet> <20090308164806.1d3fa1d7@snowcone> <20090308170104.GH14240@comet> <1236536824.9458.66.camel@neuromancer> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0et/Au7PJwzVwd4K" Content-Disposition: inline In-Reply-To: <1236536824.9458.66.camel@neuromancer> User-Agent: Mutt/1.5.18 (2008-05-17) X-Archives-Salt: 71f0cb3c-67b5-4047-aa47-9b1d19a97e86 X-Archives-Hash: 43884b49cb72b8741056bc4be242b1be --0et/Au7PJwzVwd4K Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 19:27 Sun 08 Mar , Tiziano M=FCller wrote: > Am Sonntag, den 08.03.2009, 10:01 -0700 schrieb Donnie Berkholz: > > It would just eliminate all but one call to use_with(). Depending on ho= w=20 > > many you've got, this can shorten things up a fair bit. Here's an=20 > > example: > >=20 > > econf \ > > $(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk') >=20 > The above could be rewritten to: >=20 > ECONF_USE_WITH=3D"'x X' 'foo libfoo' 'bar' 'python pygtk'" > econf $(use_with ${ECONF_USE_WITH}) Why would I want to obfuscate my code like that by purposely making=20 people look in multiple places to figure out what it's doing? I don't=20 see how this is any improvement. > or an eclass could even export this: >=20 > src_configure() { > [ -n ${ECONF_USE_WITH} ] && USE_WITH=3D"$(use_with > \"${ECONF_USE_WITH}\")" > econf ${USE_WITH} > } >=20 > Guessing from what I see in the gnome/kde eclasses I think people will > implement the above then in eclasses and I therefore don't see why we > can't do it like that from the beginning... If it can be implemented in an eclass, why would we want to do it as an=20 EAPI in a package manager? Eclasses can be easily changed, you only need=20 to write them once, and you don't have to deal with updating & approving=20 a spec and new implementation for a bug in the previous implementation=20 (which you have to retain indefinitely). --=20 Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com --0et/Au7PJwzVwd4K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEABECAAYFAkm0Q8UACgkQXVaO67S1rtv/xQCgwFd1hPPUvsLZokYilvocPpxG a40AoNkT4yT3qzCG6yby7nC80ju/VAtB =3gPM -----END PGP SIGNATURE----- --0et/Au7PJwzVwd4K--