1 |
On Sun, Nov 09, 2008 at 03:39:12PM +0300, Peter Volkov wrote: |
2 |
> В Сбт, 08/11/2008 в 17:20 -0500, Thomas Anderson пишет: |
3 |
> > This is a reposting of a call for discussion on DEFAULT_* variables. |
4 |
> > The original discussion was at [1]. |
5 |
> 1. Functions we have now are much more flexible then proposed arrays. Do |
6 |
> I need to think of some example of code that is impossible to do with |
7 |
> arrays but still possible with functions? |
8 |
|
9 |
And more complex. Remember, I said that these proposals were not for |
10 |
every case. Showing how it can't be used in one case says nothing about |
11 |
it otherwise being used. |
12 |
|
13 |
> 2. Much simpler? No, it's not: |
14 |
> |
15 |
> (2.1) Such arrays do not not reduce the number of keys to be pressed. |
16 |
> They require even more typing for small ebuilds [3] (example proposed by |
17 |
> you, btw) and the only example which expose some improvement (presented |
18 |
> by Santiago M. Mola[4]) shows that we still didn't learned how to use |
19 |
> syntax we already have and (2.2) some extensions to the current syntax |
20 |
> will just complicate things. Look if you remove $myconf variable from |
21 |
> that ebuild[4], remove || die after econf and in EAPI=2 you can drop |
22 |
> emake || die you'll see that the gain is small even for such medium size |
23 |
> ebuild. |
24 |
> At the same time this new syntax make some things worse: |
25 |
|
26 |
Here's an example of how much gain there is with this approach: |
27 |
http://tinyurl.com/6jj8a5 |
28 |
|
29 |
> 1. it hides real code under this variables. |
30 |
As mentioned, so do use_enable, use_with, emake(though these are |
31 |
functions hiding code, DOCS. Hiding code is not always a bad thing. |
32 |
|
33 |
> 2. having variable like DEFAULT_RSC_PREPARE_PATCHES will promote bad |
34 |
> practice of using patches instead of sed. |
35 |
|
36 |
How so? We already have a ton of PATCHES variables as mentioned. How is |
37 |
this standardization of what we already have going to promote bad |
38 |
practices? |
39 |
|
40 |
> 3. SUCH_LONG_VARIABLES_IN_CAPS are always harder to read [5] and thus |
41 |
> easier to do typo in them (like you did in DEFAULT_RSC_PREPARE_PATCHES, |
42 |
> btw). (highlighting helps here but does not makes that variables easier |
43 |
> to read or type in?) |
44 |
|
45 |
Ok, so you could find a different name. The names aren't really |
46 |
important. You could use USE_ENABLES and USE_WITHS and DEFAULT_PATCHES. |
47 |
|
48 |
> 4. "it also conflates multiple concepts into a single variable name (the |
49 |
> function name, whether it's USE-dependent, and how the configure flag is |
50 |
> passed)." (-- Donnie Berkholz [6]) |
51 |
> |
52 |
> 5. "One of the great things about ebuilds is that they're very natural |
53 |
> to write in most cases, if you can manage to build the program by hand. |
54 |
> Raising this barrier of entry for questionable benefit seems like a bad |
55 |
> idea." (-- Donnie Berkholz [7]) |
56 |
|
57 |
No one is raising the barrier. People can continue to use use_enable and |
58 |
use_with as they have for ages. The only thing that changes is that |
59 |
ebuild devs now have another way(which is simpler from my experience and |
60 |
that of others) to write ebuilds. Also, it's not that more |
61 |
|
62 |
> |
63 |
> So, why to reiterate this discussion without providing clear answer to |
64 |
> the above concerns? |
65 |
> |
66 |
Because we came up with a more comprehensive proposal covering more |
67 |
phase functions. |
68 |
> |
69 |
> At the same time default src_install is different proposal and having it |
70 |
> implemented is a good idea. |
71 |
> |
72 |
> |
73 |
> [1] http://article.gmane.org/gmane.linux.gentoo.devel/57990 |
74 |
> [2] http://article.gmane.org/gmane.linux.gentoo.devel/58728 |
75 |
> [3] http://thread.gmane.org/gmane.linux.gentoo.devel/57990 |
76 |
> [4] http://article.gmane.org/gmane.linux.gentoo.devel/57996 |
77 |
> [5] http://archive.devwebpro.com/devwebpro-39-200305063ReasonsNotToUseUppercase.html |
78 |
> [6] http://article.gmane.org/gmane.linux.gentoo.devel/58061 |
79 |
> [7] http://article.gmane.org/gmane.linux.gentoo.devel/58051 |
80 |
> |
81 |
> -- |
82 |
> Peter. |
83 |
> |