Re: [gentoo-dev] DEFAULT_* proposal

["Santiago M. Mola" <coldwind@gentoo.org>]

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

Hello,

El dom, 09-11-2008 a las 15:39 +0300, Peter Volkov escribió:
> 
> 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?
> 

The same concern was raised in the default src_install proposal. Making
default functions a bit more flexible doesn't mean we need default
functions which cover every possible case, that's just impossible.

> 
> At the same time this new syntax make some things worse:

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

As shown in the proposal, this variable is already used in many eclasses
and it has been proven useful.

I'm not sure the existence of PATCHES is promoting any kind of "patch
abuse". As far as I know, it's more common the concern about abusing sed
for things that should be patched rather than the other way.

But, in any case, both methods would still be available:

	src_prepare {
		epatch "${FILESDIR}"/some-stuff.patch
		sed -i -e "s:FOO:BAR:g" Makefile
	}

would still be correct.

If someone is using the PATCHES variable like this:

	PATCHES=( 'stome-stuff.patch' 'more-patches.patch' ... ... ... )

a sed call would be easy to add if needed as follows:

	PATCHES=( 'stome-stuff.patch' 'more-patches.patch' ... ... ... )

	src_prepare() {
		default
		sed -i -e "s:FOO:BAR:g" Makefile
	}


It's quite straight-forward.

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

This is the easier part to address. If these names are a problem, other
names can be used. For example, what it's called
DEFAULT_SRC_INSTALL_DOCS in this proposal, it's called just DOCS in
others.

If people likes this approach better, then similar names can be chosen
for the rest of proposed variables. For example:

DEFAULT_SRC_PREPARE_PATCHES -> PATCHES, EPATCHES...
DEFAULT_SRC_CONFIGURE_ENABLES -> ECONF_ENABLES
DEFAULT_SRC_COMPILE_PARAMS -> EMAKE_PARAMS, EMAKE_EXTRA_PARAMS...

Anyway, it'd be better if people focus on discussing the actual
functionality rather than the chosen names.

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

ECONF_USE_ENABLES might solve that problem.

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

Functions would still be overridable. And, in fact, they will need to be
overriden in many cases. There's no change there. With respect this
"barrier", it already exists with the many eclasses we have.

Regards,
-- 
Santiago Moisés Mola
Jabber: cooldwind@gmail.com | GPG: AAD203B5

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 197 bytes --]