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

[Pacho Ramos]

El dom, 23-09-2012 a las 12:40 +0200, Michał Górny escribió:
> On Sun, 23 Sep 2012 12:33:58 +0200
> Pacho Ramos <pacho@g.o> wrote:
>
> > 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@g.o> wrote:
> > >
> > > > Matt Turner schrieb:
> > > > > On Sat, Sep 22, 2012 at 2:24 PM, 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.
> > > > >
> > > > > 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
>
> Qt uses cmake, doesn't it?
>
> I don't mind having cmake-multilib as well? We could probably move
> the foreach_abi() function to some more common eclass, like multilib
> eclass.
>

Looks interesting, yes, it uses cmake. I guess we would need to move all
packages needing 32bits libs to this eclasses. Are you sure wouldn't be
better to try to go to an "upper" level like Alexis Ballier suggested
some messages ago?:
"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 ?

-- this really starts to resemble multilib portage :)"

That would be better as there are a ton of ebuilds not inheritting
autotools-utils.eclass even being autotools based (think for example in
gnome packages or many others)