From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1KzAu9-00057a-61 for garchives@archives.gentoo.org; Sun, 09 Nov 2008 14:04:41 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0EACEE029D; Sun, 9 Nov 2008 14:04:41 +0000 (UTC) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by pigeon.gentoo.org (Postfix) with ESMTP id D356CE029D for ; Sun, 9 Nov 2008 14:04:40 +0000 (UTC) Received: by an-out-0708.google.com with SMTP id d40so184557and.1 for ; Sun, 09 Nov 2008 06:04:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent:sender; bh=x3YShEXhAGUihLT8akcEjOhtWEp7hX3EwZCAT7JfAYo=; b=V5ZFQket2Pjg6YScLFhpay9VKBAfi7u75IPSwHA+82nNozlh9eCV7uHmIdI/CCfYZE x7LF43JiCeHid/pkWtr66kF2Nzo/zmIGr6UbtYJt00ZvJEvVhYLGLThQPrQQHlPHBt6i htQIOWJGGFn6BrN5p3ydKZWXfJz/h1hdaqglk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent:sender; b=Y0ILRUEPYCqp6QLxYtcHXz5J0uJnKr0JTSRdocYFhI8C81HCCJ0ZnWimF9EnjJ2NOA j0+FcVBbKW2r2v11hznj43lIuWL2JxVOxV0OIjubIUpq4kmXbJ2J+FTeiekSG2RjZzVP 2V54tdMvjXi4Q4oqYMMQskdlgwUDg3RK88He0= Received: by 10.100.119.17 with SMTP id r17mr1252883anc.130.1226239479072; Sun, 09 Nov 2008 06:04:39 -0800 (PST) Received: from smtp.gmail.com (c-69-249-154-72.hsd1.nj.comcast.net [69.249.154.72]) by mx.google.com with ESMTPS id d29sm8964751and.41.2008.11.09.06.04.37 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Nov 2008 06:04:38 -0800 (PST) Received: by smtp.gmail.com (nbSMTP-1.00) for uid 1001 (using TLSv1/SSLv3 with cipher RC4-MD5 (128/128 bits)) gentoofan23@gentoo.org; Sun, 9 Nov 2008 09:04:38 -0500 (EST) Date: Sun, 9 Nov 2008 09:04:37 -0500 From: Thomas Anderson To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] DEFAULT_* proposal Message-ID: <20081109140437.GA5200@spoc> References: <20081108222051.GA7464@spoc> <1226234352.27750.175.camel@localhost> 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="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: <1226234352.27750.175.camel@localhost> User-Agent: Mutt/1.5.16 (2007-06-09) Sender: Thomas Anderson X-Archives-Salt: 98a4e92f-aea6-45c3-9014-019d8523bd4d X-Archives-Hash: 67594bccd11462c25b4e9da4c141479f --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 09, 2008 at 03:39:12PM +0300, Peter Volkov wrote: > =D0=92 =D0=A1=D0=B1=D1=82, 08/11/2008 =D0=B2 17:20 -0500, Thomas Anderson= =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > This is a reposting of a call for discussion on DEFAULT_* variables. > > The original discussion was at [1]. > 1. Functions we have now are much more flexible then proposed arrays. Do > I need to think of some example of code that is impossible to do with > arrays but still possible with functions? And more complex. Remember, I said that these proposals were not for every case. Showing how it can't be used in one case says nothing about it otherwise being used. > 2. Much simpler? No, it's not: >=20 > (2.1) Such arrays do not not reduce the number of keys to be pressed. > They require even more typing for small ebuilds [3] (example proposed by > you, btw) and the only example which expose some improvement (presented > by Santiago M. Mola[4]) shows that we still didn't learned how to use > syntax we already have and (2.2) some extensions to the current syntax > will just complicate things. Look if you remove $myconf variable from > that ebuild[4], remove || die after econf and in EAPI=3D2 you can drop > emake || die you'll see that the gain is small even for such medium size > ebuild. > At the same time this new syntax make some things worse: Here's an example of how much gain there is with this approach: http://tinyurl.com/6jj8a5 > 1. it hides real code under this variables. As mentioned, so do use_enable, use_with, emake(though these are functions hiding code, DOCS. Hiding code is not always a bad thing. > 2. having variable like DEFAULT_RSC_PREPARE_PATCHES will promote bad > practice of using patches instead of sed. How so? We already have a ton of PATCHES variables as mentioned. How is this standardization of what we already have going to promote bad practices? > 3. SUCH_LONG_VARIABLES_IN_CAPS are always harder to read [5] and thus > easier to do typo in them (like you did in DEFAULT_RSC_PREPARE_PATCHES, > btw). (highlighting helps here but does not makes that variables easier > to read or type in?) Ok, so you could find a different name. The names aren't really important. You could use USE_ENABLES and USE_WITHS and DEFAULT_PATCHES. > 4. "it also conflates multiple concepts into a single variable name (the > function name, whether it's USE-dependent, and how the configure flag is > passed)." (-- Donnie Berkholz [6]) >=20 > 5. "One of the great things about ebuilds is that they're very natural > to write in most cases, if you can manage to build the program by hand. > Raising this barrier of entry for questionable benefit seems like a bad= =20 > idea." (-- Donnie Berkholz [7]) No one is raising the barrier. People can continue to use use_enable and use_with as they have for ages. The only thing that changes is that ebuild devs now have another way(which is simpler from my experience and that of others) to write ebuilds. Also, it's not that more >=20 > So, why to reiterate this discussion without providing clear answer to > the above concerns? >=20 Because we came up with a more comprehensive proposal covering more phase functions. >=20 > At the same time default src_install is different proposal and having it > implemented is a good idea. >=20 >=20 > [1] http://article.gmane.org/gmane.linux.gentoo.devel/57990 > [2] http://article.gmane.org/gmane.linux.gentoo.devel/58728 > [3] http://thread.gmane.org/gmane.linux.gentoo.devel/57990 > [4] http://article.gmane.org/gmane.linux.gentoo.devel/57996 > [5] http://archive.devwebpro.com/devwebpro-39-200305063ReasonsNotToUseUpp= ercase.html > [6] http://article.gmane.org/gmane.linux.gentoo.devel/58061 > [7] http://article.gmane.org/gmane.linux.gentoo.devel/58051 >=20 > --=20 > Peter. >=20 --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkkW7fUACgkQF6yMcaBxwHmCqwCfRFZQxXu1xuS98gHwacDxht1F RN4An3ouHJYyRHRafnUlDSBS+Z3SzoWN =KXjU -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G--