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 1Kcg8r-00032x-3r for garchives@archives.gentoo.org; Mon, 08 Sep 2008 12:46:53 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3180FE0271; Mon, 8 Sep 2008 12:46:52 +0000 (UTC) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by pigeon.gentoo.org (Postfix) with ESMTP id D2486E0271 for ; Mon, 8 Sep 2008 12:46:51 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id A7181198E92 for ; Mon, 8 Sep 2008 14:46:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 9AA64198E7A for ; Mon, 8 Sep 2008 14:46:50 +0200 (CEST) Received: from wmax001.mathematik.uni-wuerzburg.de (wmax001.mathematik.uni-wuerzburg.de [132.187.61.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 84C17198E69 for ; Mon, 8 Sep 2008 14:46:50 +0200 (CEST) Date: Mon, 8 Sep 2008 14:46:42 +0200 (CEST) From: Vaeth To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile In-Reply-To: Message-ID: References: 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: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Archives-Salt: f8768874-0104-48c2-a60b-ca22ccd145a0 X-Archives-Hash: a0510ad8af13794826a29c2687ad96ed Alec Warner wrote: > Vaeth wrote: > > > (Moreover, in most cases, > > this would not even save some characters, because the variable > > names would have to be much longer...) > > I don't think the variable names are really in scope (we can chose > them arbitrarily). But you cannot choose them much smaller unless you want to decrease readability even more. > I disagree with less readable; it is less intuitive The point is that in contrast to shell code you need additional pre-knowledge to read or write it. > the syntax looks fine and the syntax is in fact still bash. I do not want to start a discussion now whether this is implicit semantic or sort of an extended syntax - it depends on the point of view. But in any case it involves new (and actually redundant) "keywords" in the ebuild. > However, ebuilds are already > sufficiently complicated by eclass inheritance that reading > many ebuilds is already difficult This is the point. For certain very specialized eclasses like kde or qt this might be inavoidable, but one should strive to minimize these things as much as possible. So an idea how to go into the *opposite* direction is what is actually needed. > and I think this extension does not make that significantly worse. "because we made some mistakes anyway let us make even more..." > Arguing about intentions is not really a compelling argument. Spec It is, if something does not satisfy (anymore) what is supposed to do. > files have more than magic variables too; many have > similar constructs to ebuilds (postinst and prerm phases, file > manifests, etc.) Specfiles and ebuilds are more alike than different. Yes, meanwhile specfiles and ebuilds are very similar which is really a problem: It is not accidental that many users of other distributions prefer to install into /usr/local instead of writing rpms - most users do not want to learn a specification. It is fatal if ebuilds go the same road. The knowledge needed to write or read ebuilds should be kept as small as possible.