1 |
On Wed, 23 Jan 2013 21:36:22 +0400 |
2 |
Alexey Shvetsov <alexxy@g.o> wrote: |
3 |
|
4 |
> В письме от 23 января 2013 08:03:56 пользователь Alexis Ballier |
5 |
> написал: |
6 |
> > On Wed, 23 Jan 2013 09:24:26 +0100 |
7 |
> > |
8 |
> > Michał Górny <mgorny@g.o> wrote: |
9 |
> > > On Mon, 21 Jan 2013 10:27:30 -0300 |
10 |
> > > |
11 |
> > > Alexis Ballier <aballier@g.o> wrote: |
12 |
> > > > > To be honest, I don't know if there's other way to hide USE |
13 |
> > > > > flags than using USE_EXPAND_HIDDEN. If we want to use that, |
14 |
> > > > > we'd have |
15 |
> > > > > |
16 |
> > > > > to split the flags per-arch, i.e. have: |
17 |
> > > > > MULTILIB_AMD64="abi1 abi2 abi3" |
18 |
> > > > > MULTILIB_PPC64="abi1 abi2 abi3" |
19 |
> > > > > |
20 |
> > > > > with appropriate USE_EXPAND_HIDDEN set by profiles. |
21 |
> > > > |
22 |
> > > > I don't like that at all. |
23 |
> > > > I'd go for ABI= the union of all the MULTILIB_ABIS variables (if |
24 |
> > > > there is no name collision) |
25 |
> > > > we certainly want skype to depend on libitneeds[abi_x86], not |
26 |
> > > > 'amd64? ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )' |
27 |
> > > |
28 |
> > > Just a quick idea. |
29 |
> > > |
30 |
> > > How would you feel about abi_x86_32? (similarly _64, _x32) |
31 |
> > > |
32 |
> > > That would be almost natural names with the trick variable being |
33 |
> > > ABI_X86, therefore having all the fore-mentioned advantages. |
34 |
> > > |
35 |
> > > The deps would look like: |
36 |
> > > libitneeds[abi_x86_32] |
37 |
> > |
38 |
> > Sounds good too, I just would want it to be shared between arches |
39 |
> > that can: amd64/x86/x32, ppc/ppc64, mips, sparc32/sparc64, etc. |
40 |
> > You mean you will hide ABI_X86 USE_EXPAND on non-x86 arches, right ? |
41 |
> > This would have all the benefits I think, very good idea :) |
42 |
> > |
43 |
> > Alexis. |
44 |
> |
45 |
> Shared abi names are bad idea. For example |
46 |
> mips abis : |
47 |
> o32 |
48 |
> n32 |
49 |
> n64 |
50 |
> eabi |
51 |
> x86: |
52 |
> x86_32 |
53 |
> x86_x32 |
54 |
> x86_64 |
55 |
> |
56 |
> Actualy first three one are equivalent in their internal behavior. |
57 |
> But i dont think that its good idea to have one name for all. |
58 |
|
59 |
Sorry, I don't get it. What was meant here was one USE_EXPAND variable |
60 |
per group of similar arches. Different abis are, of course, |
61 |
distinguished within each variable. |
62 |
|
63 |
> Think |
64 |
> about multiarch installs where you can have binaries from different |
65 |
> architectures in one system. |
66 |
|
67 |
It depends what we want through multilib. I personally think multiarch |
68 |
is out of scope: there is crossdev for that. |
69 |
|
70 |
Alexis. |