1 |
On Wed, 03 Apr 2013 11:40:31 +0200 |
2 |
Thomas Sachau <tommy@g.o> wrote: |
3 |
|
4 |
> Michał Górny schrieb: |
5 |
> > Hello, |
6 |
> > |
7 |
> > Currently, the multilib-build eclass uses abi_* constants only for USE |
8 |
> > flags and only ${ABI} is exported to the function. This is bad since it |
9 |
> > basically requires a reverse mapping of ABI->abi_* values, often |
10 |
> > inlined as ${ABI} checks. |
11 |
> > |
12 |
> > The patches which I will send in reply to this thread aim to fix it. |
13 |
> > |
14 |
> > The first patch changes the eclass logic. The abi_* values, with 'abi_' |
15 |
> > prefix stripped, are called MULTILIB_ABI now. They are used to run |
16 |
> > the 'foreach' functions, and now are set in the called functions along |
17 |
> > with ABI. |
18 |
> > |
19 |
> > As a downside, the switch required the MULTILIB_ABI -> ABI mapping to |
20 |
> > occur inside foreach -- as in, another 'for' loop. It shouldn't cause |
21 |
> > any noticeable difference. |
22 |
> > |
23 |
> > Additionally, the 'default' fallback no longer calls |
24 |
> > multilib_toolchain_setup. This should improve compatibility with |
25 |
> > multilib-portage and *maybe* cross-compiling. |
26 |
> |
27 |
> You know, that multilib-portage does use MULTILIB_ABI as USE-expanded |
28 |
> variable? Using exactly the same in the eclass will call for collision |
29 |
> issues. |
30 |
|
31 |
Argv. Could you suggest a new name then? |
32 |
|
33 |
-- |
34 |
Best regards, |
35 |
Michał Górny |