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

[Pacho Ramos <pacho@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]

El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> On Sun, 23 Sep 2012 11:07:30 +0200
> Thomas Sachau <tommy@gentoo.org> wrote:
> 
> > Matt Turner schrieb:
> > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > >> It is a simple eclass using autotools out-of-source builds to build
> > >> packages for multiple ABIs when multilib is supported.
> > > 
> > > Thanks a lot, Michał! This looks good to me.
> > > 
> > >> Use case: xorg packages, ask Matt.
> > > 
> > > So the idea is that users want up-to-date 32-bit drivers for games and
> > > WINE. The emul- packages aren't a very good solution for a number of
> > > reasons.
> > > 
> > > I'd like to add multilib USE flags to Mesa and thus its dependencies.
> > > I realized that almost everything in x11-libs/ could be converted very
> > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > > addition to emul-linux-x86-opengl.
> > > 
> > > 
> > 
> > This looks like a shortened duplication of a subset of multilib-portage
> > features. While this wont hurt multilib-portage (since it does exclude
> > most actions on ebuilds with USE=multilib), it will mean a rewrite for
> > many ebuilds, which then again need another rewrite (or more likely
> > revert), when multilib-portage is accepted in a future EAPI.
> 
> s/when/if/
> 
> > So i would prefer some help/support with multilib-portage to get it
> > accepted sooner, instead of this additional workaround for a subset of
> > packages.
> 
> I prefer the simpler solution.
> 
> > P.S.: I know, that users, who want up-to-date 32bit drivers for games
> > and wine do use multilib-portage, so we already have a working solution
> > for this issue.
> 
> They will no longer have to do that.
> 

I would prefer if eclass way could be extended to packages not using
autotools too, otherwise, we will still need emul packages for, for
example, qt libs. If that would be possible via eclass, maybe
multilib-portage wouldn't be needed but, if not, we will still need it
and, then, would be nice if this inclussion for autotools packages
wouldn't cause more problems to get the "strong" solution land in the
"near" future :/

The simpler solution (eclass) looks fine to me, but it would need to be
extended to more packages than autotools based ones to let it replace
portage-multilib/emul packages

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]