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 ? > 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. > > -- this really starts to resemble multilib portage :) > > I've said already that multilib is a thing which could be done by > eclasses and doesn't need making PM scary. And Tommy says that > multilib-portage handles packages having IUSE=multilib fine. I agree with that, it also has two main advantages over multilib portage: it can be used right now and ensures that packages have their multilib builds tested before exposing it to users. A.
