| 1 |
On Sun, 20 Jan 2013 20:11:31 +0100 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> Hello, |
| 5 |
> |
| 6 |
> There is a fair interest in multilib and while still early, it would be |
| 7 |
> a good moment to decide on how USE flags to use for it. |
| 8 |
> |
| 9 |
> The current attempts are mostly using USE=multilib which is not really |
| 10 |
> expressive and poor. What I would go for is a clear variable specifying |
| 11 |
> which targets package is built for. |
| 12 |
|
| 13 |
You just need to add 'ABI' and 'MULTILIB_ABIS' to |
| 14 |
"emerge --info ${pkg}" output. |
| 15 |
|
| 16 |
Do you plan to keep precise depends for packages? |
| 17 |
like glibc[abi_x32]/gcc[abi_x32] for all libraries requesting x32. |
| 18 |
|
| 19 |
What to do if someone builds a package only with non-default ABI? |
| 20 |
(it means installed package does not quite work for default ABI) |
| 21 |
|
| 22 |
like on ABI=amd64 media-libs/glu[ABI=x32] could not be used by |
| 23 |
any of ABI=amd64 users. |
| 24 |
|
| 25 |
In order to track such depends precisely you would need to add |
| 26 |
ABI flags to each revdep recursively. It's quite invasive. Is it worth |
| 27 |
the effort? |
| 28 |
|
| 29 |
Currently USE=multilib means 'build for all toolchain-supported' ABIs. |
| 30 |
It looks clean and short. |
| 31 |
|
| 32 |
> This raises the following questions: |
| 33 |
> |
| 34 |
> 1) do we want the default ABI to be switchable? |
| 35 |
It already is via /etc/portage/env per-package. |
| 36 |
Or via profile globally. arch/amd64/make.defaults: |
| 37 |
MULTILIB_ABIS="amd64 x86" |
| 38 |
DEFAULT_ABI="amd64" |
| 39 |
|
| 40 |
crossdev allows bootstrapping with any random default |
| 41 |
ABI out there as one-liner: |
| 42 |
crossdev -A 'x32 amd64' x86_64-unknown-linux-gnu. |
| 43 |
|
| 44 |
> 2) do we want irrelevant ABIs to be visible to emerge users? |
| 45 |
> |
| 46 |
> By 2) I mean: do we want the users to see stuff like: |
| 47 |
> |
| 48 |
> MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1) |
| 49 |
> (-ppc64_abi2) (-ppc64_abi3) ..." |
| 50 |
|
| 51 |
Would adding irrelevant ABIs trigger rebuilds on world update? |
| 52 |
|
| 53 |
Do you intermingle gentoo's $ARCH and ABI? |
| 54 |
How many ABI vars do you expect to see for simple "common" cases? |
| 55 |
|
| 56 |
x86_64-pc-linux-gnu-gcc -m32 (host ARCH=amd64) |
| 57 |
x86_64-pc-linux-gnu-gcc -m64 (host ARCH=amd64) |
| 58 |
x86_64-pc-linux-gnu-gcc -mx32 (host ARCH=amd64) |
| 59 |
i686-pc-linux-gnu-gcc -m32 (host ARCH=x86) |
| 60 |
i686-pc-linux-gnu-gcc -m64 (host ARCH=x86) |
| 61 |
i686-pc-linux-gnu-gcc -mx32 (host ARCH=x86) |
| 62 |
|
| 63 |
3 or 6? |
| 64 |
|
| 65 |
Looks like insane amount of metadata growth for each |
| 66 |
plagued package. |
| 67 |
|
| 68 |
> or just the relevant part. |
| 69 |
> |
| 70 |
> To be honest, I don't know if there's other way to hide USE flags than |
| 71 |
> using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split |
| 72 |
> the flags per-arch, i.e. have: |
| 73 |
> |
| 74 |
> MULTILIB_AMD64="abi1 abi2 abi3" |
| 75 |
> MULTILIB_PPC64="abi1 abi2 abi3" |
| 76 |
> |
| 77 |
> with appropriate USE_EXPAND_HIDDEN set by profiles. |
| 78 |
|
| 79 |
Having direct support in portage's core might reduce amount of |
| 80 |
user-visible/storable metadata in main tree. No slightest idea |
| 81 |
how it would look like though. |
| 82 |
|
| 83 |
-- |
| 84 |
|
| 85 |
Sergei |
Archives