On Sun, 23 Sep 2012 12:47:44 -0300 Alexis Ballier <aball...@gentoo.org> wrote:
> On Sun, 23 Sep 2012 09:21:20 +0200 > Michał Górny <mgo...@gentoo.org> wrote: > > > On Sat, 22 Sep 2012 21:46:02 -0300 > > Alexis Ballier <aball...@gentoo.org> wrote: > > > > > On Sat, 22 Sep 2012 23:24:46 +0200 > > > Michał Górny <mgo...@gentoo.org> 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
signature.asc
Description: PGP signature
