1 |
On Sun, 27 Jan 2013 14:40:35 +0100 |
2 |
Thomas Sachau <tommy@g.o> wrote: |
3 |
|
4 |
> Michał Górny schrieb: |
5 |
> > Hello, |
6 |
> > |
7 |
> > Following all the suggestions from Alexis Ballier, I have reworked |
8 |
> > the code to remove multiple points of failure. I have also rebased it |
9 |
> > on the common multilib-build eclass concept, and updated amd64 |
10 |
> > no-multilib & x86 profiles as well. |
11 |
> > |
12 |
> > Key points: |
13 |
> > |
14 |
> > 1. The list of available flags and corresponding ABIs is now stored |
15 |
> > in a single variable. Adding a new ABI is as simple as adding |
16 |
> > a value to that variable (+ profiles). |
17 |
> > |
18 |
> > 2. All ABIs are validated against $(get_all_abis) list. This guarantees |
19 |
> > that we check only the flags proper for the arch. |
20 |
> > |
21 |
> > 3. The USE_EXPAND is visible only on amd64 multilib profile. However, |
22 |
> > it is also available on non-multilib amd64 & x86, with all flags |
23 |
> > masked except for the default one which is force-enabled. |
24 |
> > |
25 |
> > The last point means that x86 binary packages (skype) can have |
26 |
> > dependencies as simple as: |
27 |
> > |
28 |
> > dev-libs/libfoo[abi_x86_32] |
29 |
> > |
30 |
> > which would be valid both for amd64 multilib & x86. |
31 |
> > |
32 |
> > |
33 |
> > |
34 |
> |
35 |
> Lets see, if i understand your plan right, without reading all your diffs: |
36 |
> |
37 |
> 1. you currently support amd64/multilib and show same flags on |
38 |
> amd64/no-multilib and x86 to avoid duplicating the dependency list? If |
39 |
> yes, will this be extended to general support for all multilib arches, |
40 |
> only on request for specific arches or not at all? |
41 |
|
42 |
Yes and no. I do force the flags to enabled but they are hidden |
43 |
from the end-user using USE_EXPAND. |
44 |
|
45 |
I don't mind supporting any arch which likes to enable multilib. It's |
46 |
mostly about adding the flags to proper profiles and to the list |
47 |
in the eclass. But I'd rather rely on arch teams to decide on how to |
48 |
proceed with the particular arches. |
49 |
|
50 |
> 2. How do you handle other abi-specific files like headers or binaries |
51 |
> and cases like binaries with abi-specific content? Is it possible to |
52 |
> preserve them for all requested abis or to preserve them for an |
53 |
> non-default abi? |
54 |
|
55 |
The idea is that all non-libdir stuff shall be handled properly |
56 |
by ebuilds. The eclass is meant to support the most common and simplest |
57 |
case, proper and efficient handling of deviations can't be controlled |
58 |
centrally. |
59 |
|
60 |
-- |
61 |
Best regards, |
62 |
Michał Górny |