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

[Thomas Sachau <tommy@gentoo.org>]

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

Sergei Trofimovich schrieb:
> 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.
> 

Support for cross-compiling packages for toolchain-supported ABIs
already exists and works for some years in multilib-portage (code in the
multilib branch of portage git repo, ebuild in the multilib-portage
overlay with very basic setup instructions in the doc dir of the overlay
and the #gentoo-multilib-overlay channel in freenode for questions).

-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]