| 1 |
On Sun, 03 Mar 2013 16:47:43 +0100 |
| 2 |
Thomas Sachau <tommy@g.o> wrote: |
| 3 |
|
| 4 |
> Alexis Ballier schrieb: |
| 5 |
> > On Sun, 03 Mar 2013 14:02:58 +0100 |
| 6 |
> > Thomas Sachau <tommy@g.o> wrote: |
| 7 |
> >> |
| 8 |
> >> Once the eclass has per-ABI header |
| 9 |
> > |
| 10 |
> > I think this is needed. |
| 11 |
> > |
| 12 |
> >> and binaries support, |
| 13 |
> > |
| 14 |
> > but here, could you enlighten me on its use cases ? I can't imagine |
| 15 |
> > why having multi binaries support would be useful. |
| 16 |
> > |
| 17 |
> > Alexis. |
| 18 |
> > |
| 19 |
> |
| 20 |
> |
| 21 |
> At least some binaries do have abi-specific output, which is used by |
| 22 |
> other applications. As a good example of this, have a look at qmake |
| 23 |
> and qmake based build systems. |
| 24 |
|
| 25 |
hmm, qmake doesnt seem to be the perfect example: how do you handle |
| 26 |
this? |
| 27 |
|
| 28 |
- install qmake-${abi} |
| 29 |
- ln -s qmake-${DEFAULT_ABI} qmake |
| 30 |
- modify eqmake4 to call the right qmake when doing multilib? |
| 31 |
|
| 32 |
this sounds hackish for a behavior that doesn't make much sense to me |
| 33 |
(its an upstream problem here); the glxinfo example seems perfectly |
| 34 |
valid though. |
| 35 |
|
| 36 |
Alexis. |
Archives