| 1 |
Before people start asking I should explain why I started this: |
| 2 |
https://bugs.gentoo.org/show_bug.cgi?id=458638 |
| 3 |
|
| 4 |
I think having such an eclass has several advantages over |
| 5 |
autootools-multilib.eclass (which depends on autotools-utils.eclass) as |
| 6 |
it is now: |
| 7 |
|
| 8 |
a) Less eclass dependencies. One could argue: the more eclasses my |
| 9 |
ebuild uses the more prone to error and exposed to changes it is. |
| 10 |
b) easier conversion in some cases: often times a simple rename |
| 11 |
src_compile -> multilib_src_compile will do |
| 12 |
c) it allows more custom definition of phase functions |
| 13 |
d) the previous point will also allow to convert go-mono.eclass packages |
| 14 |
without introducing yet another eclass for that |
| 15 |
e) autotools-utils.eclass does a bit more than just calling default |
| 16 |
phase functions; the developer has little choice on this matter unless |
| 17 |
he wants to rewrite his ebuild based on multilib-build.eclass which will |
| 18 |
create a lot of code duplication in ebuilds, hence this proposition |
| 19 |
|
| 20 |
I don't have a problem with the present eclasses, but I find this a |
| 21 |
logical enhancement. |
Archives