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 1KccLz-0007xu-37 for garchives@archives.gentoo.org; Mon, 08 Sep 2008 08:44:11 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E84B1E0330; Mon, 8 Sep 2008 08:44:09 +0000 (UTC) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by pigeon.gentoo.org (Postfix) with ESMTP id B7950E0330 for ; Mon, 8 Sep 2008 08:44:09 +0000 (UTC) Received: by an-out-0708.google.com with SMTP id c28so280437ana.47 for ; Mon, 08 Sep 2008 01:44:08 -0700 (PDT) Received: by 10.100.202.14 with SMTP id z14mr15066641anf.138.1220863448826; Mon, 08 Sep 2008 01:44:08 -0700 (PDT) Received: by 10.70.40.7 with HTTP; Mon, 8 Sep 2008 01:44:08 -0700 (PDT) Message-ID: Date: Mon, 8 Sep 2008 01:44:08 -0700 From: "Alec Warner" Sender: antarus@scriptkitty.com To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile In-Reply-To: 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=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 9514b31710ea8907 X-Archives-Salt: b4d1fff7-3061-4748-bf41-d60aba3b3ae8 X-Archives-Hash: fc392b82fbab2649aa08e18d1ace349f On Mon, Sep 8, 2008 at 1:07 AM, Vaeth wrote: > >> Yes. And here another point should be brought up. This proposal should >> be wider and consider similar changes for the most common used >> operations on all phases. > > And in fact, the most common used operations on all phases are > already covered: Namely, this is the default implementation of the phase. > Any change from this is not so common and should therefore be based on > writing the function. Saving here some characters for typing the > function header means to save at the wrong place by making everything > less readable and less maintainable. (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). I disagree with less readable; it is less intuitive to see what is happening because there is an abstraction; but the readability of the code is not impacted; the syntax looks fine and the syntax is in fact still bash. We must make trade-offs between abstractions and intuition and we should strive to make our abstractions as intuitive as possible and I think we have mostly succeeded in doing so in a variety of cases (and we have certainly failed in others.) Most obvious failure cases these days have build logs and the build logs will specify what the configure command was, so the only problematic area is looking at the ebuild to determine what will happen during execution. Arguably having an ebuildshell would assist here. However, ebuilds are already sufficiently complicated by eclass inheritance that reading many ebuilds is already difficult and I think this extension does not make that significantly worse. Luckily the proposal does not require this syntax to be used (and there is no real reason to prevent the old syntax at this time; nor has anyone suggested we do so). At best, the proposal entails a few lines in each PM that allow ebuild authors to make simpler ebuilds. I think this is a big plus as we can reduce mistakes involving line continuation and reduce ebuild size. > > Actually, too many variables with a predefined meaning are used in > ebuilds already now. The original intention of ebuilds was that - > in contrast to .spec-files or other stuff which are some sort of > extended database - it should be simple pure shell code which everybody > can easily read or write without filling in magic data. > Things like WANT_AUTOMAKE=1.8 already violate this rule, but it seems > hard to avoid it here, because IIRC there is no "src_depend()" function > where the calculation of the dependencies could be done in a consistent > manner. But the rule should not be violated without any serious need: > If ebuilds consist only in setting magic variables, you can use .spec > as well. > > Arguing about intentions is not really a compelling argument. Spec 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. -Alec