On Mon, 24 Sep 2012 22:47:33 +0200
Michał Górny <mgo...@gentoo.org> wrote:
> On Mon, 24 Sep 2012 16:16:53 -0300
> Alexis Ballier <aball...@gentoo.org> wrote:
>
> > On Mon, 24 Sep 2012 20:12:40 +0200
> > Michał Górny <mgo...@gentoo.org> wrote:
> >
> > > > > > > > > > to some extent, can't you do the same by unpacking
> > > > > > > > > > twice to different $S and calling
> > > > > > > > > > src_prepare/compile/install instead of their
> > > > > > > > > > autotools-utils counterpart with tweaked $S so that
> > > > > > > > > > it works with almost every ebuild ?
> >
> > [...]
> >
> > > Ebuilds don't offer me anything if I have to rewrite phase
> > > functions anyway...
> >
> > what, in the above quote, makes you think you need to rewrite
> > anything ?
>
> 1. If ebuild has phase functions, they override the eclass.
> 2. If eclass exports phase functions, they have no way of calling
> 'previous' eclass phase functions.
>
you dont need this, the PM has already done the work for you: call
directly the relevant function.
src_multilib_compile() {
forall ABIS; do
prepare ABI variables
src_compile
done
}
then, in a future EAPI, let the PM call src_multilib_compile instead
of src_compile if multilib is requested.
this needs very minimal PM/EAPI support, leaves the multilib code
into eclasses, leaves multilib opt-in so that noarch or packages not
installing a lib dont need to care, and also leaves room for cleaner
more specific eclasses like yours
