Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs

[Alexis Ballier <aballier@gentoo.org>]

On Sun, 3 Mar 2013 17:58:26 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> On Sun, 03 Mar 2013 17:27:50 +0100
> Thomas Sachau <tommy@gentoo.org> wrote:
> 
> > Alexis Ballier schrieb:
> > > On Sun, 03 Mar 2013 16:47:43 +0100
> > > Thomas Sachau <tommy@gentoo.org> wrote:
> > > 
> > >> Alexis Ballier schrieb:
> > >>> On Sun, 03 Mar 2013 14:02:58 +0100
> > >>> Thomas Sachau <tommy@gentoo.org> wrote:
> > >>>>
> > >>>> Once the eclass has per-ABI header
> > >>>
> > >>> I think this is needed.
> > >>>
> > >>>> and binaries support,
> > >>>
> > >>> but here, could you enlighten me on its use cases ? I can't
> > >>> imagine why having multi binaries support would be useful.
> > >>>
> > >>> Alexis.
> > >>>
> > >>
> > >>
> > >> At least some binaries do have abi-specific output, which is
> > >> used by other applications. As a good example of this, have a
> > >> look at qmake and qmake based build systems.
> > > 
> > > hmm, qmake doesnt seem to be the perfect example: how do you
> > > handle this?
> > > 
> > > - install qmake-${abi}
> > 
> > ok
> > 
> > > - ln -s qmake-${DEFAULT_ABI} qmake
> > 
> > Just the same as with headers:
> > 
> > You dont symlink the headers for the default ABI, but instead a
> > wrapper is placed, which does then call/include the real target, so
> > in this case, qmake is then a symlink to the abiwrapper, which does
> > execute the real abi-specific binary, depending on the current ABI.
> > We can of course place this abiwrapper in every place, where it is
> > needed instead of the symlink, but having one central and package
> > provided wrapper instead is easier to maintain and update.
> > 
> > > - modify eqmake4 to call the right qmake when doing multilib?
> > 
> > not needed at all (with multilib-portage), since when any package
> > calls qmake to get any abi-specific details, the abiwrapper
> > executes the binary, that matches the ABI and you get the right
> > details for your ABI.
> 
> What do we need that wrapper for? What does the wrapper do? Does it
> just rely on custom 'ABI' variable?

yes -- it must perform some checks though.

> Or maybe should it try to detect
> whether it was called by a 64- or 32-bit app?

this wont work: think about a build system, your shell/make will likely
be your default abi's but may call abi-specific tools depending on what
you build _for_ not what you build _with_

> What for?

in order to be transparent from the ebuild perspective.

> It's just a needless complexity, a big tool to handle a few corner
> cases. Alexis just pointed out a perfectly good way of handling it.

well, I don't like the way of handling it I pointed out to be honest :p

Alexis.