On Mon, 24 Sep 2012 17:44:33 -0700
Matt Turner <mattst88@gentoo.org> wrote:

> On Mon, Sep 24, 2012 at 3:22 PM, Alexis Ballier <aballier@gentoo.org>
> wrote:
> > On Tue, 25 Sep 2012 00:10:21 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> >
> >> On Mon, 24 Sep 2012 18:59:14 -0300
> >> Alexis Ballier <aballier@gentoo.org> wrote:
> >>
> >> > On Mon, 24 Sep 2012 23:51:27 +0200
> >> > Michał Górny <mgorny@gentoo.org> wrote:
> >> >
> >> > > On Mon, 24 Sep 2012 18:19:43 -0300
> >> > > Alexis Ballier <aballier@gentoo.org> wrote:
> >> > >
> >> > > > you dont need this, the PM has already done the work for you:
> >> > > > call directly the relevant function.
> >> > > >
> >> > > > src_multilib_compile() {
> >> > > > forall ABIS; do
> >> > > > prepare ABI variables
> >> > > > src_compile
> >> > > > done
> >> > > > }
> >> > >
> >> > > Err, what? Who calls the function? Where?
> >> >
> >> > bash. here.
> >>
> >> How can an eclass call a phase function while eclass needs to be
> >> called from the phase function to call the phase function...?
> >>
> >
> > Read again. Esp. the part you deleted.
> > I never said it should do this, on purpose...
> >
>
> I'm especially confused by what your point is. I can't see how your
> snippet could ever work, and you're being evasive about answering
> that.
>

both of you are putting words in my mouth then: obviously, if you call
your eclass multilib and the above function multilib_src_compile and
then pass it through EXPORT_FUNCTIONS, then it will loop.

let me copy paste what i wrote for you:

"""
then, in a future EAPI, let the PM call src_multilib_compile instead
of src_compile if multilib is requested.
"""

nothing more...

On Sun, 23 Sep 2012 16:49:13 +0200
Thomas Sachau <tommy@gentoo.org> 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.