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 1LgX09-0005jP-56 for garchives@archives.gentoo.org; Mon, 09 Mar 2009 04:22:05 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 332A0E047B; Mon, 9 Mar 2009 04:22:04 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 124A8E047B for ; Mon, 9 Mar 2009 04:22:04 +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 97F0064ADE for ; Mon, 9 Mar 2009 04:22:03 +0000 (UTC) Date: Sun, 8 Mar 2009 21:22:03 -0700 From: Donnie Berkholz To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Ideas for a (fast) EAPI=3 Message-ID: <20090309042202.GC6343@comet.hsd1.or.comcast.net> References: <1236498557.6854.51.camel@neuromancer> <20090308164228.GG14240@comet> <20090308164806.1d3fa1d7@snowcone> <20090308170104.GH14240@comet> <1236536824.9458.66.camel@neuromancer> <20090308221637.GP14240@comet> <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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eRtJSFbw+EEWtPj3" Content-Disposition: inline In-Reply-To: <1236551752.9458.82.camel@neuromancer> User-Agent: Mutt/1.5.18 (2008-05-17) X-Archives-Salt: d7ef04b8-999c-446a-bd5a-2b2b60cecfe9 X-Archives-Hash: 0dc6ee5f2e646b90785f87afbd6fc0a5 --eRtJSFbw+EEWtPj3 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 23:35 Sun 08 Mar , Tiziano M=FCller wrote: > Well, the point I'm trying to make here is a different one: The syntax=20 > you proposed is more to write but still equivalent to the one using=20 > vars. And looking at the ebuilds - taking G2CONF as an example - it=20 > seems that people don't have a problem with putting their config=20 > options into vars. And furthermore with your syntax you still have to=20 > write out "econf $(use_with ...)" explicitly while adding it the=20 > conf-vars to a var (as proposed) makes the complete src_configure=20 > function obsolete, allows the usage of the default=20 > src_configure/src_compile/src_install (see=20 > http://archives.gentoo.org/gentoo-dev/msg_17e6ae8082aeb762fd01ba730745778= 9.xml=20 > for example) and is therefore even shorter to write. I think the idea of ebuilds as scripts showing directly how to build=20 software is a core part of the Gentoo build-system philosophy. This=20 proposal pushes ebuilds toward a formatted file that is not a script.=20 Instead, it is more like an Ant XML file that more abstractly describes=20 a build. I think this is the wrong direction for ebuilds because they=20 should directly resemble how software is built by hand. One of the key reasons people use Gentoo is that ebuilds are so easy to=20 "get" for anyone who has ever built software by hand. I will continue to=20 vehemently defend anything that I think retains this key advantage of=20 Gentoo over other distributions. --=20 Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com --eRtJSFbw+EEWtPj3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEABECAAYFAkm0mWoACgkQXVaO67S1rtt1MgCcDtMGz3YHfyQ0YOvPEuc+wKtu 4AAAoM08r4KMTfL7UIACGAgHpGqoJrem =vKrO -----END PGP SIGNATURE----- --eRtJSFbw+EEWtPj3--