[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
From:       Alexis Ballier <aballier () gentoo ! org>
Date:       2012-09-25 13:21:41
Message-ID: 20120925102141.2923c03c () gentoo ! org
[Download RAW message or body]

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.

[prev in list] [next in list] [prev in thread] [next in thread]