Before people start asking I should explain why I started this:
https://bugs.gentoo.org/show_bug.cgi?id=458638

I think having such an eclass has several advantages over
autootools-multilib.eclass (which depends on autotools-utils.eclass) as
it is now:

a) Less eclass dependencies. One could argue: the more eclasses my
ebuild uses the more prone to error and exposed to changes it is.
b) easier conversion in some cases: often times a simple rename
src_compile -> multilib_src_compile will do
c) it allows more custom definition of phase functions
d) the previous point will also allow to convert go-mono.eclass packages
without introducing yet another eclass for that
e) autotools-utils.eclass does a bit more than just calling default
phase functions; the developer has little choice on this matter unless
he wants to rewrite his ebuild based on multilib-build.eclass which will
create a lot of code duplication in ebuilds, hence this proposition

I don't have a problem with the present eclasses, but I find this a
logical enhancement.

Reply via email to