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

[Alexis Ballier]

On Thu, 03 Jan 2013 11:44:58 +0100
Thomas Sachau <tommy@g.o> wrote:

> Pacho Ramos schrieb:
> > 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 ?
>
> I dont really understand your question here. So do you:
>
> - simply have 2 64bit apps wanting to use ffmpeg?
> - have 2 32bit binary packages wanting to use ffmpeg?
> - want to build foo and bar on a 64bit platform for a 32bit platform?
> - want a 64bit or a 32bit version of ffmpeg or both?
> - if you want a 32bit version of ffmpeg, do you only want 32bit libs
> or also a 32bit binary?


it depends on what you are building; let's say we want all abi flavors
for foo and bar.

in the above example, package foo uses fork/exec so needs a libc
compatible with its abis and that's all; it doesn't care if ffmpeg is
an elf executable, a bash script, or running through an emulator.
package bar needs ffmpeg libraries for every abi it installs.
portage multilib doesn't seem to distinguish between the two cases.

> >> - 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.
>
> Isnt "out-of-tree build" just building in a seperate location, so in
> the end doing one unpack instead of 2, while everything else still
> needs to be done for each target?

yes, so?
(unpack in the EAPI0 sense btw, prepare shouldn't need to be done twice
either)

> >> 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 :)
>
> Please keep in mind, that the USE flags are different, depending on
> your arch. E.g. on amd64, you may additionally have x86 and x32,
> while on ppc64, you may have ppc64 and ppc. You dont want the later
> on amd64 nor the first on ppc. So how do you want to add different
> (use-expanded) USE flags based on the arch the user is running?

no, the useflags are not different:

coma=""
for i in $MULTILIB_ABIS ; do
    multilib_use_deps+="${coma}multilib_abi_${i}?"
    coma=", "
done

deps like foo[multilib?] becomes foo[${multilib_use_deps}]
and voila, you are not anymore limited to multilib or not multilib but
really control the abis.

> >> 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 ?
>
> While the variable export, the build for each target and the merge of
> the results should also be possible inside an eclass, the dependency
> and USE flag parts seems more tricky.

Even with what I've written above ? Why ?

> And additionally, with support of this in (multilib-)portage (not
> depending on EAPI, but enabled via FEATURES), i already get all of
> this without having to wait for a new EAPI/eclass and ebuilds moving
> to it.

You don't need an EAPI then, just get your changes merged in portage.

Alexis.