Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib

[Sergei Trofimovich <slyfox@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2904 bytes --]

On Sun, 20 Jan 2013 20:11:31 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> Hello,
> 
> There is a fair interest in multilib and while still early, it would be
> a good moment to decide on how USE flags to use for it.
> 
> The current attempts are mostly using USE=multilib which is not really
> expressive and poor. What I would go for is a clear variable specifying
> which targets package is built for.

You just need to add 'ABI' and 'MULTILIB_ABIS' to
"emerge --info ${pkg}" output.

Do you plan to keep precise depends for packages?
like glibc[abi_x32]/gcc[abi_x32] for all libraries requesting x32.

What to do if someone builds a package only with non-default ABI?
(it means installed package does not quite work for default ABI)

like on ABI=amd64 media-libs/glu[ABI=x32] could not be used by
any of ABI=amd64 users.

In order to track such depends precisely you would need to add
ABI flags to each revdep recursively. It's quite invasive. Is it worth
the effort?

Currently USE=multilib means 'build for all toolchain-supported' ABIs.
It looks clean and short.

> This raises the following questions:
> 
> 1) do we want the default ABI to be switchable?
It already is via /etc/portage/env per-package.
Or via profile globally. arch/amd64/make.defaults:
  MULTILIB_ABIS="amd64 x86"                                                                                
  DEFAULT_ABI="amd64"

crossdev allows bootstrapping with any random default
ABI out there as one-liner:
    crossdev -A 'x32 amd64' x86_64-unknown-linux-gnu.

> 2) do we want irrelevant ABIs to be visible to emerge users?
> 
> By 2) I mean: do we want the users to see stuff like:
> 
>   MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1)
>     (-ppc64_abi2) (-ppc64_abi3) ..."

Would adding irrelevant ABIs trigger rebuilds on world update?

Do you intermingle gentoo's $ARCH and ABI?
How many ABI vars do you expect to see for simple "common" cases?

  x86_64-pc-linux-gnu-gcc -m32 (host ARCH=amd64)
  x86_64-pc-linux-gnu-gcc -m64 (host ARCH=amd64)
  x86_64-pc-linux-gnu-gcc -mx32 (host ARCH=amd64)
  i686-pc-linux-gnu-gcc -m32 (host ARCH=x86)
  i686-pc-linux-gnu-gcc -m64 (host ARCH=x86)
  i686-pc-linux-gnu-gcc -mx32 (host ARCH=x86)

3 or 6?

Looks like insane amount of metadata growth for each
plagued package.

> or just the relevant part.
> 
> To be honest, I don't know if there's other way to hide USE flags than
> using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split
> the flags per-arch, i.e. have:
> 
>   MULTILIB_AMD64="abi1 abi2 abi3"
>   MULTILIB_PPC64="abi1 abi2 abi3"
> 
> with appropriate USE_EXPAND_HIDDEN set by profiles.

Having direct support in portage's core might reduce amount of
user-visible/storable metadata in main tree. No slightest idea
how it would look like though.

-- 

  Sergei

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]