On Sun, 3 Mar 2013 17:58:26 +0100 Michał Górny <[email protected]> wrote:
> On Sun, 03 Mar 2013 17:27:50 +0100 > Thomas Sachau <[email protected]> wrote: > > > Alexis Ballier schrieb: > > > On Sun, 03 Mar 2013 16:47:43 +0100 > > > Thomas Sachau <[email protected]> wrote: > > > > > >> Alexis Ballier schrieb: > > >>> On Sun, 03 Mar 2013 14:02:58 +0100 > > >>> Thomas Sachau <[email protected]> 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.
