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 1LgRbJ-0002MZ-2z for garchives@archives.gentoo.org; Sun, 08 Mar 2009 22:36:05 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0F28CE0320; Sun, 8 Mar 2009 22:36:04 +0000 (UTC) Received: from smtp.tmcs.ch (113.245.131.213.static.inetbone.net [213.131.245.113]) by pigeon.gentoo.org (Postfix) with ESMTP id B9B29E0320 for ; Sun, 8 Mar 2009 22:36:03 +0000 (UTC) Received: from [192.168.0.100] (78-206.3-85.cust.bluewin.ch [85.3.206.78]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.tmcs.ch (Postfix) with ESMTPSA id 009CD16B1B99 for ; Sun, 8 Mar 2009 23:36:02 +0100 (CET) Subject: Re: [gentoo-dev] Ideas for a (fast) EAPI=3 From: Tiziano =?ISO-8859-1?Q?M=FCller?= To: gentoo-dev@lists.gentoo.org In-Reply-To: <20090308221637.GP14240@comet> References: <1236498557.6854.51.camel@neuromancer> <20090308164228.GG14240@comet> <20090308164806.1d3fa1d7@snowcone> <20090308170104.GH14240@comet> <1236536824.9458.66.camel@neuromancer> <20090308221637.GP14240@comet> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-tRwp86FEOZzfFJcfEoNJ" Organization: Gentoo Date: Sun, 08 Mar 2009 23:35:52 +0100 Message-Id: <1236551752.9458.82.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 X-Mailer: Evolution 2.24.5 X-Archives-Salt: 945813e5-e5ca-4b64-916a-c03e2fe7483d X-Archives-Hash: f1bf4ffa6479cd6025cc72077bf7075b --=-tRwp86FEOZzfFJcfEoNJ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Am Sonntag, den 08.03.2009, 15:16 -0700 schrieb Donnie Berkholz: > On 19:27 Sun 08 Mar , Tiziano M=C3=BCller 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 = how=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}) >=20 > 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. >=20 > > 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... >=20 > 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). Well, the point I'm trying to make here is a different one: The syntax you proposed is more to write but still equivalent to the one using vars. And looking at the ebuilds - taking G2CONF as an example - it seems that people don't have a problem with putting their config options into vars. And furthermore with your syntax you still have to write out "econf $(use_with ...)" explicitly while adding it the conf-vars to a var (as proposed) makes the complete src_configure function obsolete, allows the usage of the default src_configure/src_compile/src_install (see http://archives.gentoo.org/gentoo-dev/msg_17e6ae8082aeb762fd01ba7307457789.= xml for example) and is therefore even shorter to write. --=-tRwp86FEOZzfFJcfEoNJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEABECAAYFAkm0SEgACgkQGwVqY66cHjDf2ACfaWHn0AT8rYIWjuB/AEPS5+bS quMAn2k6kkT740JCI41/Yum35p8kCW4Y =AQB9 -----END PGP SIGNATURE----- --=-tRwp86FEOZzfFJcfEoNJ--