[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
pgpD38QL2RFMY.pgp
Description: PGP signature
