Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Alec Warner]

On Mon, Sep 8, 2008 at 1:07 AM, Vaeth <vaeth@××××××××××××××××××××××××.de> 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