1 |
On Sun, 3 Mar 2013 17:58:26 +0100 |
2 |
Michał Górny <mgorny@g.o> wrote: |
3 |
|
4 |
> On Sun, 03 Mar 2013 17:27:50 +0100 |
5 |
> Thomas Sachau <tommy@g.o> wrote: |
6 |
> |
7 |
> > Alexis Ballier schrieb: |
8 |
> > > On Sun, 03 Mar 2013 16:47:43 +0100 |
9 |
> > > Thomas Sachau <tommy@g.o> wrote: |
10 |
> > > |
11 |
> > >> Alexis Ballier schrieb: |
12 |
> > >>> On Sun, 03 Mar 2013 14:02:58 +0100 |
13 |
> > >>> Thomas Sachau <tommy@g.o> wrote: |
14 |
> > >>>> |
15 |
> > >>>> Once the eclass has per-ABI header |
16 |
> > >>> |
17 |
> > >>> I think this is needed. |
18 |
> > >>> |
19 |
> > >>>> and binaries support, |
20 |
> > >>> |
21 |
> > >>> but here, could you enlighten me on its use cases ? I can't |
22 |
> > >>> imagine why having multi binaries support would be useful. |
23 |
> > >>> |
24 |
> > >>> Alexis. |
25 |
> > >>> |
26 |
> > >> |
27 |
> > >> |
28 |
> > >> At least some binaries do have abi-specific output, which is |
29 |
> > >> used by other applications. As a good example of this, have a |
30 |
> > >> look at qmake and qmake based build systems. |
31 |
> > > |
32 |
> > > hmm, qmake doesnt seem to be the perfect example: how do you |
33 |
> > > handle this? |
34 |
> > > |
35 |
> > > - install qmake-${abi} |
36 |
> > |
37 |
> > ok |
38 |
> > |
39 |
> > > - ln -s qmake-${DEFAULT_ABI} qmake |
40 |
> > |
41 |
> > Just the same as with headers: |
42 |
> > |
43 |
> > You dont symlink the headers for the default ABI, but instead a |
44 |
> > wrapper is placed, which does then call/include the real target, so |
45 |
> > in this case, qmake is then a symlink to the abiwrapper, which does |
46 |
> > execute the real abi-specific binary, depending on the current ABI. |
47 |
> > We can of course place this abiwrapper in every place, where it is |
48 |
> > needed instead of the symlink, but having one central and package |
49 |
> > provided wrapper instead is easier to maintain and update. |
50 |
> > |
51 |
> > > - modify eqmake4 to call the right qmake when doing multilib? |
52 |
> > |
53 |
> > not needed at all (with multilib-portage), since when any package |
54 |
> > calls qmake to get any abi-specific details, the abiwrapper |
55 |
> > executes the binary, that matches the ABI and you get the right |
56 |
> > details for your ABI. |
57 |
> |
58 |
> What do we need that wrapper for? What does the wrapper do? Does it |
59 |
> just rely on custom 'ABI' variable? |
60 |
|
61 |
yes -- it must perform some checks though. |
62 |
|
63 |
> Or maybe should it try to detect |
64 |
> whether it was called by a 64- or 32-bit app? |
65 |
|
66 |
this wont work: think about a build system, your shell/make will likely |
67 |
be your default abi's but may call abi-specific tools depending on what |
68 |
you build _for_ not what you build _with_ |
69 |
|
70 |
> What for? |
71 |
|
72 |
in order to be transparent from the ebuild perspective. |
73 |
|
74 |
> It's just a needless complexity, a big tool to handle a few corner |
75 |
> cases. Alexis just pointed out a perfectly good way of handling it. |
76 |
|
77 |
well, I don't like the way of handling it I pointed out to be honest :p |
78 |
|
79 |
Alexis. |