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 <gentoo-dev+bounces-33369-garchives=archives.gentoo.org@lists.gentoo.org>)
	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 <gentoo-dev@lists.gentoo.org>; Sun,  9 Nov 2008 14:04:40 +0000 (UTC)
Received: by an-out-0708.google.com with SMTP id d40so184557and.1
        for <gentoo-dev@lists.gentoo.org>; 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 <gentoofan23@gentoo.org>
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: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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 <gentoofan23@gmail.com>
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--