Gentoo Archives: gentoo-dev

From: Peter Volkov <pva@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] DEFAULT_* proposal
Date: Sun, 09 Nov 2008 12:39:43
Message-Id: 1226234352.27750.175.camel@localhost
In Reply to: [gentoo-dev] DEFAULT_* proposal by Thomas Anderson
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.

Replies

Subject Author
Re: [gentoo-dev] DEFAULT_* proposal Thomas Anderson <gentoofan23@g.o>
Re: [gentoo-dev] DEFAULT_* proposal "Santiago M. Mola" <coldwind@g.o>