| 1 |
[RFC] Simplifying functions with variables and help from the PM |
| 2 |
|
| 3 |
Hello All; |
| 4 |
This is a reposting of a call for discussion on DEFAULT_* variables. |
| 5 |
The original discussion was at [1]. The general idea is making the |
| 6 |
default functions support some new variables so that they are more |
| 7 |
flexible. |
| 8 |
|
| 9 |
Here are the function(in order of execution) changes I propose, but |
| 10 |
let me first remind you that these changes are for the default |
| 11 |
package manager implementation of the functions. Each proposal is |
| 12 |
separate but it'd be nice if they all went in the same EAPI so it |
| 13 |
doesn't get confusing. |
| 14 |
|
| 15 |
src_prepare: |
| 16 |
DEFAULT_RSC_PREPARE_PATCHES[] |
| 17 |
This is a bash arrary list of patches to be applied to the |
| 18 |
sources. This is implemented as PATCHES or similar variables |
| 19 |
in a lot of eclasses like base, bzr, git, horde, kde, ruby, |
| 20 |
ruby-gnome2, subversion and x-modular but they all have unneeded |
| 21 |
differences. We'll need a function(say builtin_epatch, but |
| 22 |
better names are needed) in the PM to handle patching. |
| 23 |
|
| 24 |
src_configure: |
| 25 |
DEFAULT_SRC_CONFIGURE_USE_ENABLES[] |
| 26 |
An array whose constants are passed as arguments to |
| 27 |
`use_enable`. Each value of the array can have two parts. |
| 28 |
DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'a52 a52dec' ) would |
| 29 |
translate to $(use_enable a52 a52dec). |
| 30 |
|
| 31 |
DEFAULT_SRC_CONFIGURE_USE_WITHS[] |
| 32 |
Same as above, but s/enable/with/ |
| 33 |
|
| 34 |
DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS[] |
| 35 |
Array of options to pass to econf |
| 36 |
|
| 37 |
src_compile: |
| 38 |
DEFAULT_SRC_COMPILE_PARAMS[] |
| 39 |
Array of options to pass to emake |
| 40 |
|
| 41 |
src_install: |
| 42 |
All I want changed here is a variable for a list of extra docs to be |
| 43 |
installed. This'll require a default function for |
| 44 |
src_install and I propose: |
| 45 |
src_install() { |
| 46 |
emake -j1 install DESTDIR="${D}" || die "make install died" |
| 47 |
[[ -n ${DEFAULT_SRC_INSTALL_DOCS} ]] && dodoc \ |
| 48 |
${DEFAULT_SRC_INSTALL_DOCS} |
| 49 |
} |
| 50 |
bug #33544 has more information on this topic, as does |
| 51 |
tommy's recent thread on the subject of default src_install |
| 52 |
function. |
| 53 |
|
| 54 |
In my experience, these features greatly enhance ebuilds and make |
| 55 |
the ebuilds simpler to write(before objecting to this point, read |
| 56 |
the original thread[1] and/or use the feature), read, and maintain. |
| 57 |
|
| 58 |
Also, one point I cannot stress enough is that this is not meant for |
| 59 |
every ebuild but for the majority of simple cases. |
| 60 |
|
| 61 |
Now, last time around, objections were made to the effect that the |
| 62 |
src_configure proposal hides things in the PM which makes the |
| 63 |
learning curve higer and hides things from the ebuild viewer. My |
| 64 |
position on this is that it hides stuff in the same way that |
| 65 |
`use_enable mp3` hides `use mp3 && echo "--enable-mp3" || echo |
| 66 |
"--disable-mp3"`. In other words, not all cases where you move |
| 67 |
thinsg to the PM are bad. |
| 68 |
|
| 69 |
Credit for this idea goes to those who made the exheres package |
| 70 |
format(used for the Exherbo linux distribution) and those who |
| 71 |
participated in the discussion on bug #33544 over the past who knows |
| 72 |
how many years. |
| 73 |
|
| 74 |
Please discuss! |
| 75 |
Thomas Anderson |
| 76 |
|
| 77 |
|
| 78 |
|
| 79 |
[1]: http://article.gmane.org/gmane.linux.gentoo.devel/58038 |
Archives