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