On Mon, Sep 8, 2008 at 1:07 AM, Vaeth <[EMAIL PROTECTED]> 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
