[RFC] Simplifying functions with variables and help from the PM

Hello All;
	This is a reposting of a call for discussion on DEFAULT_* variables.
	The original discussion was at [1]. The general idea is making the
	default functions support some new variables so that they are more
	flexible. 

	Here are the function(in order of execution) changes I propose, but
	let me first remind you that these changes are for the default
	package manager implementation of the functions. Each proposal is
	separate but it'd be nice if they all went in the same EAPI so it
	doesn't get confusing.

		src_prepare:
			DEFAULT_RSC_PREPARE_PATCHES[]
			This is a bash arrary list of patches to be applied to the
			sources. This is implemented as PATCHES or similar variables
			in a lot of eclasses like base, bzr, git, horde, kde, ruby,
			ruby-gnome2, subversion and x-modular but they all have unneeded
			differences. We'll need a function(say builtin_epatch, but 
			better names are needed) in the PM to handle patching.

		src_configure:
			DEFAULT_SRC_CONFIGURE_USE_ENABLES[]
			An array whose constants are passed as arguments to
			`use_enable`. Each value of the array can have two parts.
			DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'a52 a52dec' ) would
			translate to $(use_enable a52 a52dec).

			DEFAULT_SRC_CONFIGURE_USE_WITHS[]
			Same as above, but s/enable/with/

			DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS[]
			Array of options to pass to econf

		src_compile:
			DEFAULT_SRC_COMPILE_PARAMS[]
			Array of options to pass to emake

		src_install:
			All I want changed here is a variable for a list of extra docs to be
			installed. This'll require a default function for
			src_install and I propose:
				src_install() {
					emake -j1 install DESTDIR="${D}" || die "make install died"
					[[ -n ${DEFAULT_SRC_INSTALL_DOCS} ]] && dodoc \
					${DEFAULT_SRC_INSTALL_DOCS}
				}
			bug #33544 has more information on this topic, as does
			tommy's recent thread on the subject of default src_install
			function.

	In my experience, these features greatly enhance ebuilds and make
	the ebuilds simpler to write(before objecting to this point, read
	the original thread[1] and/or use the feature), read, and maintain.

	Also, one point I cannot stress enough is that this is not meant for
	every ebuild but for the majority of simple cases.

	Now, last time around, objections were made to the effect that the
	src_configure proposal hides things in the PM which makes the
	learning curve higer and hides things from the ebuild viewer. My
	position on this is that it hides stuff in the same way that
	`use_enable mp3` hides `use mp3 && echo "--enable-mp3" || echo
	"--disable-mp3"`. In other words, not all cases where you move
	thinsg to the PM are bad.

	Credit for this idea goes to those who made the exheres package
	format(used for the Exherbo linux distribution) and those who
	participated in the discussion on bug #33544 over the past who knows
	how many years.

Please discuss!
Thomas Anderson



[1]: http://article.gmane.org/gmane.linux.gentoo.devel/58038