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

[Pacho Ramos]

El mar, 25-09-2012 a las 10:21 -0300, Alexis Ballier escribió:
> On Sun, 23 Sep 2012 16:49:13 +0200
> Thomas Sachau <tommy@g.o> wrote:
>
> > It is not hard by itself to inherit an eclass. There is just the
> > limitation, that occurs with an eclass, e.g.:
> >
> > -the one from mgorny only does it for autotools based ebuilds only and
> > even there only for libraries, headers and binaries are not done.
> > While one may create the same for cmake based ones, those are still
> > only for a subset of packages, since not all do use autotools/cmake
> > or are satisfied with a libs only solution
> > -the multilib-native eclass does extend it way more, but still has its
> > limitations, e.g. what happens with a new target ABI (like x32 on the
> > amd64 profile) or how are dependencies handled?
> >
> > multilib-portage is the answer to those limitations, since it does
> > work for any target with multilib cross-compile support, can handle
> > things like the dependencies internally and can even work on not
> > prepared/modified ebuilds.
> >
> > So before i invest even more time in getting this official, we should
> > better get to some conclusion, if we either go the route with eclass
> > based multilib cross-compile support with its limitations or if we
> > move this up to the package manager level.
> >
>
> Can't we get something in between ?
>
> Unless I'm mistaken, portage-multilib has its limitations also:
>
> - I have package foo and package bar, both depending on ffmpeg and
> canditates for a multilib build. However, package foo does not link to
> ffmpeg but simply spawns the 'ffmpeg' binary to process some files,
> package bar links to libavcodec. You need ffmpeg[multilib] for a
> multilib build of bar but not for foo. How do you distinguish between
> the two ?
>
> - When an out-of-tree build is possible, it is more efficient to do it
>   that way while multilib-portage will probably run the full src_*
>   phases twice. mgorny's eclass is a solution to this for
>   autotools-utils based ebuilds. I have added basic support for this in
>   freebsd-lib some time ago also.
>
>
>
> However, it is clear that USE=multilib is limited too. What we probably
> need, as I read in the draft you posted some time ago, is a
> MULTILIB_ABI use-expand. Keep a list of all the MULTILIB_ABIs in an
> eclass, add them to IUSE of multilib-enabled packages and then you can
> use the USE-deps. When a new ABI gets added, add it to the list in the
> eclass and be done. You already have PM support for this :)
>
> You can leverage the generic multilib building code you have to an
> eclass, so that you don't need to spec it; spec-ing it has its problems
> too: what happens if next year pkg-config is deprecated and now we
> shall all use foo-config ? your spec adjusts PKG_CONFIG_PATH but not
> FOO_CONFIG_PATH. You probably need a small EAPI change to be able to
> implement sanely a generic solution into an eclass though.
>
> My question to you would be: what are we missing from current EAPIs to
> be able to perfectly support multilib builds ?
>
> A.
>
>

What finally occurred with this? What would be the problem of opting by
this "mixed" solution (eclass for some packages and PM features
requiring newer eapi for others)?

Thanks