Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

On Sun, 23 Sep 2012 12:47:44 -0300
Alexis Ballier <aballier@g.o> wrote:

> On Sun, 23 Sep 2012 09:21:20 +0200
> Michał Górny <mgorny@g.o> wrote:
>
> > On Sat, 22 Sep 2012 21:46:02 -0300
> > Alexis Ballier <aballier@g.o> wrote:
> >
> > > On Sat, 22 Sep 2012 23:24:46 +0200
> > > Michał Górny <mgorny@g.o> wrote:
> > >
> > > > It is a simple eclass using autotools out-of-source builds to
> > > > build packages for multiple ABIs when multilib is supported.
> > > >
> > >
> > > 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 ?
> >
> > That would make this solution inefficient.
>
> Why ?

Because it introduces unnecessarily copying files around.

> > The good solutions should
> > not be made ugly to support corner cases.
>
> You are tying support to one specific build system, and one specific
> usage within ebuilds. That is what I would call a corner case :)
> Ebuilds already define a standardized way of building packages, why not
> use this directly ?
> I'm not saying your proposal is useless, it is indeed more efficient
> than a generic one, but rather that a generic solution is neither much
> more complicated nor that inefficient in comparison.

It's a common case.

A generic solution is more complicated if it is supposed to use phase
functions exported by some eclass. By using a generic solution you lose
the ability to 'automagically' use last exported function.

Some time ago I suggested replacing 'default' with something like
'next' (which would allow one exported phase function to call the one
from next inherited eclass) but I don't think I got any response.

-- 
Best regards,
Michał Górny