Re: [gentoo-dev] DEFAULT_* proposal

[Thomas Anderson <gentoofan23@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3793 bytes --]

On Sun, Nov 09, 2008 at 03:39:12PM +0300, Peter Volkov wrote:
> В Сбт, 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].
> 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?

And more complex. Remember, I said that these proposals were not for
every case. Showing how it can't be used in one case says nothing about
it otherwise being used.

> 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:

Here's an example of how much gain there is with this approach:
http://tinyurl.com/6jj8a5

> 1. it hides real code under this variables.
As mentioned, so do use_enable, use_with, emake(though these are
functions hiding code, DOCS. Hiding code is not always a bad thing.

> 2. having variable like DEFAULT_RSC_PREPARE_PATCHES will promote bad
> practice of using patches instead of sed.

How so? We already have a ton of PATCHES variables as mentioned. How is
this standardization of what we already have going to promote bad
practices?

> 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?)

Ok, so you could find a different name. The names aren't really
important. You could use USE_ENABLES and USE_WITHS and DEFAULT_PATCHES.

> 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])

No one is raising the barrier. People can continue to use use_enable and
use_with as they have for ages. The only thing that changes is that
ebuild devs now have another way(which is simpler from my experience and
that of others) to write ebuilds. Also, it's not that more

> 
> So, why to reiterate this discussion without providing clear answer to
> the above concerns?
> 
Because we came up with a more comprehensive proposal covering more
phase functions.
> 
> 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.
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]