1 |
В Сбт, 08/11/2008 в 17:20 -0500, Thomas Anderson пишет: |
2 |
> This is a reposting of a call for discussion on DEFAULT_* variables. |
3 |
> The original discussion was at [1]. |
4 |
|
5 |
How does this proposal answers concerns raised during last discussion? |
6 |
|
7 |
I did my best and reread all the discussions and both proposals. I found |
8 |
two reasons supporting this change is that it makes ebuilds more |
9 |
"flexible"[1] or "much simpler"[2]. With all due respect I disagree. |
10 |
|
11 |
1. Functions we have now are much more flexible then proposed arrays. Do |
12 |
I need to think of some example of code that is impossible to do with |
13 |
arrays but still possible with functions? |
14 |
|
15 |
2. Much simpler? No, it's not: |
16 |
|
17 |
(2.1) Such arrays do not not reduce the number of keys to be pressed. |
18 |
They require even more typing for small ebuilds [3] (example proposed by |
19 |
you, btw) and the only example which expose some improvement (presented |
20 |
by Santiago M. Mola[4]) shows that we still didn't learned how to use |
21 |
syntax we already have and (2.2) some extensions to the current syntax |
22 |
will just complicate things. Look if you remove $myconf variable from |
23 |
that ebuild[4], remove || die after econf and in EAPI=2 you can drop |
24 |
emake || die you'll see that the gain is small even for such medium size |
25 |
ebuild. |
26 |
|
27 |
At the same time this new syntax make some things worse: |
28 |
|
29 |
1. it hides real code under this variables. |
30 |
|
31 |
2. having variable like DEFAULT_RSC_PREPARE_PATCHES will promote bad |
32 |
practice of using patches instead of sed. |
33 |
|
34 |
3. SUCH_LONG_VARIABLES_IN_CAPS are always harder to read [5] and thus |
35 |
easier to do typo in them (like you did in DEFAULT_RSC_PREPARE_PATCHES, |
36 |
btw). (highlighting helps here but does not makes that variables easier |
37 |
to read or type in?) |
38 |
|
39 |
4. "it also conflates multiple concepts into a single variable name (the |
40 |
function name, whether it's USE-dependent, and how the configure flag is |
41 |
passed)." (-- Donnie Berkholz [6]) |
42 |
|
43 |
5. "One of the great things about ebuilds is that they're very natural |
44 |
to write in most cases, if you can manage to build the program by hand. |
45 |
Raising this barrier of entry for questionable benefit seems like a bad |
46 |
idea." (-- Donnie Berkholz [7]) |
47 |
|
48 |
|
49 |
So, why to reiterate this discussion without providing clear answer to |
50 |
the above concerns? |
51 |
|
52 |
|
53 |
At the same time default src_install is different proposal and having it |
54 |
implemented is a good idea. |
55 |
|
56 |
|
57 |
[1] http://article.gmane.org/gmane.linux.gentoo.devel/57990 |
58 |
[2] http://article.gmane.org/gmane.linux.gentoo.devel/58728 |
59 |
[3] http://thread.gmane.org/gmane.linux.gentoo.devel/57990 |
60 |
[4] http://article.gmane.org/gmane.linux.gentoo.devel/57996 |
61 |
[5] http://archive.devwebpro.com/devwebpro-39-200305063ReasonsNotToUseUppercase.html |
62 |
[6] http://article.gmane.org/gmane.linux.gentoo.devel/58061 |
63 |
[7] http://article.gmane.org/gmane.linux.gentoo.devel/58051 |
64 |
|
65 |
-- |
66 |
Peter. |