1 |
On Mon, Sep 8, 2008 at 1:07 AM, Vaeth <vaeth@××××××××××××××××××××××××.de> wrote: |
2 |
> |
3 |
>> Yes. And here another point should be brought up. This proposal should |
4 |
>> be wider and consider similar changes for the most common used |
5 |
>> operations on all phases. |
6 |
> |
7 |
> And in fact, the most common used operations on all phases are |
8 |
> already covered: Namely, this is the default implementation of the phase. |
9 |
> Any change from this is not so common and should therefore be based on |
10 |
> writing the function. Saving here some characters for typing the |
11 |
> function header means to save at the wrong place by making everything |
12 |
> less readable and less maintainable. (Moreover, in most cases, |
13 |
> this would not even save some characters, because the variable |
14 |
> names would have to be much longer...) |
15 |
|
16 |
I don't think the variable names are really in scope (we can chose |
17 |
them arbitrarily). |
18 |
|
19 |
I disagree with less readable; it is less intuitive to see what is |
20 |
happening because there |
21 |
is an abstraction; but the readability of the code is not impacted; |
22 |
the syntax looks fine and the syntax |
23 |
is in fact still bash. We must make trade-offs between abstractions |
24 |
and intuition and we should strive to make |
25 |
our abstractions as intuitive as possible and I think we have mostly |
26 |
succeeded in doing so in a variety of cases (and we |
27 |
have certainly failed in others.) |
28 |
|
29 |
Most obvious failure cases these days have build logs and the build |
30 |
logs will specify what the configure command |
31 |
was, so the only problematic area is looking at the ebuild to |
32 |
determine what will happen during execution. Arguably having |
33 |
an ebuildshell would assist here. However, ebuilds are already |
34 |
sufficiently complicated by eclass inheritance that reading |
35 |
many ebuilds is already difficult and I think this extension does not |
36 |
make that significantly worse. Luckily the proposal does not |
37 |
require this syntax to be used (and there is no real reason to prevent |
38 |
the old syntax at this time; nor has anyone suggested we do so). |
39 |
|
40 |
At best, the proposal entails a few lines in each PM that allow ebuild |
41 |
authors to make simpler ebuilds. I think this is a big plus as we can |
42 |
reduce mistakes involving line continuation and reduce ebuild size. |
43 |
|
44 |
|
45 |
|
46 |
> |
47 |
> Actually, too many variables with a predefined meaning are used in |
48 |
> ebuilds already now. The original intention of ebuilds was that - |
49 |
> in contrast to .spec-files or other stuff which are some sort of |
50 |
> extended database - it should be simple pure shell code which everybody |
51 |
> can easily read or write without filling in magic data. |
52 |
> Things like WANT_AUTOMAKE=1.8 already violate this rule, but it seems |
53 |
> hard to avoid it here, because IIRC there is no "src_depend()" function |
54 |
> where the calculation of the dependencies could be done in a consistent |
55 |
> manner. But the rule should not be violated without any serious need: |
56 |
> If ebuilds consist only in setting magic variables, you can use .spec |
57 |
> as well. |
58 |
> |
59 |
> |
60 |
|
61 |
Arguing about intentions is not really a compelling argument. Spec |
62 |
files have more than magic variables too; many have |
63 |
similar constructs to ebuilds (postinst and prerm phases, file |
64 |
manifests, etc.) Specfiles and ebuilds are more alike than different. |
65 |
|
66 |
-Alec |