autotools-multilib: wrapper eclass for multilib builds.
 

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...

autotools-multilib: wrapper eclass for multilib builds.
 

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.