From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A3E321385A8 for ; Sun, 20 Jan 2013 22:06:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BFD5921C08A; Sun, 20 Jan 2013 22:06:32 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A0E6F21C042 for ; Sun, 20 Jan 2013 22:06:31 +0000 (UTC) Received: from sf (unknown [178.121.14.254]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: slyfox) by smtp.gentoo.org (Postfix) with ESMTPSA id AC40133DAFD; Sun, 20 Jan 2013 22:06:29 +0000 (UTC) Date: Mon, 21 Jan 2013 01:05:56 +0300 From: Sergei Trofimovich To: gentoo-dev@lists.gentoo.org Cc: mgorny@gentoo.org Subject: Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib Message-ID: <20130121010556.27f8fac6@sf> In-Reply-To: <20130120201131.5afcbf48@pomiocik.lan> References: <20130120201131.5afcbf48@pomiocik.lan> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.12; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/vbif=2IheYPNNj2PFR8LgLl"; protocol="application/pgp-signature" X-Archives-Salt: 0799f0a6-dd3c-40d5-848d-be11d4133c13 X-Archives-Hash: 2018e633a99aa72216397c8d6e340679 --Sig_/vbif=2IheYPNNj2PFR8LgLl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, 20 Jan 2013 20:11:31 +0100 Micha=C5=82 G=C3=B3rny wrote: > Hello, >=20 > 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. >=20 > The current attempts are mostly using USE=3Dmultilib 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=3Damd64 media-libs/glu[ABI=3Dx32] could not be used by any of ABI=3Damd64 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=3Dmultilib means 'build for all toolchain-supported' ABIs. It looks clean and short. > This raises the following questions: >=20 > 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=3D"amd64 x86" = =20 DEFAULT_ABI=3D"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? >=20 > By 2) I mean: do we want the users to see stuff like: >=20 > MULTILIB_ABIS=3D"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=3Damd64) x86_64-pc-linux-gnu-gcc -m64 (host ARCH=3Damd64) x86_64-pc-linux-gnu-gcc -mx32 (host ARCH=3Damd64) i686-pc-linux-gnu-gcc -m32 (host ARCH=3Dx86) i686-pc-linux-gnu-gcc -m64 (host ARCH=3Dx86) i686-pc-linux-gnu-gcc -mx32 (host ARCH=3Dx86) 3 or 6? Looks like insane amount of metadata growth for each plagued package. > or just the relevant part. >=20 > 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: >=20 > MULTILIB_AMD64=3D"abi1 abi2 abi3" > MULTILIB_PPC64=3D"abi1 abi2 abi3" >=20 > 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. --=20 Sergei --Sig_/vbif=2IheYPNNj2PFR8LgLl Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlD8akcACgkQcaHudmEf86oEpACffJYk5L2wBnx8pN6LtawUS3RC LwEAnjpUVIxbxD1BlrTw/8GXE5GvCrZx =TAbT -----END PGP SIGNATURE----- --Sig_/vbif=2IheYPNNj2PFR8LgLl--