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 2EF6213862C for ; Wed, 23 Jan 2013 17:36:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 98A8F21C05F; Wed, 23 Jan 2013 17:36:26 +0000 (UTC) Received: from omrb.pnpi.spb.ru (omrb.pnpi.spb.ru [91.151.181.195]) by pigeon.gentoo.org (Postfix) with ESMTP id 402A021C043 for ; Wed, 23 Jan 2013 17:36:25 +0000 (UTC) Received: from x230i.localnet (unknown [79.173.81.171]) by omrb.pnpi.spb.ru (Postfix) with ESMTPSA id DF8FF4E95C for ; Wed, 23 Jan 2013 21:36:23 +0400 (MSK) From: Alexey Shvetsov To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib Date: Wed, 23 Jan 2013 21:36:22 +0400 Message-ID: <1379020.gIisfkuREL@x230i> User-Agent: KMail/4.10 rc3 (Linux/3.7.2-gentoo; KDE/4.9.98; x86_64; ; ) In-Reply-To: <20130123080356.11ee5f6a@gentoo.org> References: <20130120201131.5afcbf48@pomiocik.lan> <20130123092426.56745d6b@pomiocik.lan> <20130123080356.11ee5f6a@gentoo.org> 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; boundary="nextPart3418030.mxXZTPvBOM"; micalg="pgp-sha256"; protocol="application/pgp-signature" Content-Transfer-Encoding: 7Bit X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, UNPARSEABLE_RELAY autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on omrb.omrb.pnpi.spb.ru.local X-Archives-Salt: 0b225845-c29d-4ea0-966c-2275d8598841 X-Archives-Hash: 7f63278179c42d4a3a5bace90537e83b --nextPart3418030.mxXZTPvBOM Content-Type: multipart/alternative; boundary="nextPart3831615.KVpofZDGor" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart3831615.KVpofZDGor Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" =D0=92 =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=B5 =D0=BE=D1=82 23 =D1=8F=D0=BD= =D0=B2=D0=B0=D1=80=D1=8F 2013 08:03:56 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0= =BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Alexis Ballier =D0=BD=D0=B0=D0=BF= =D0=B8=D1=81=D0=B0=D0=BB: > On Wed, 23 Jan 2013 09:24:26 +0100 >=20 > Micha=C5=82 G=C3=B3rny wrote: > > On Mon, 21 Jan 2013 10:27:30 -0300 > >=20 > > Alexis Ballier wrote: > > > > To be honest, I don't know if there's other way to hide USE fla= gs > > > > than using USE_EXPAND_HIDDEN. If we want to use that, we'd have= > > > >=20 > > > > to split the flags per-arch, i.e. have: > > > > MULTILIB_AMD64=3D"abi1 abi2 abi3" > > > > MULTILIB_PPC64=3D"abi1 abi2 abi3" > > > >=20 > > > > with appropriate USE_EXPAND_HIDDEN set by profiles. > > >=20 > > > I don't like that at all. > > > I'd go for ABI=3D the union of all the MULTILIB_ABIS variables (i= f > > > there is no name collision) > > > we certainly want skype to depend on libitneeds[abi_x86], not > > > 'amd64? ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )' > >=20 > > Just a quick idea. > >=20 > > How would you feel about abi_x86_32? (similarly _64, _x32) > >=20 > > That would be almost natural names with the trick variable being > > ABI_X86, therefore having all the fore-mentioned advantages. > >=20 > > The deps would look like: > > libitneeds[abi_x86_32] >=20 > Sounds good too, I just would want it to be shared between arches tha= t > can: amd64/x86/x32, ppc/ppc64, mips, sparc32/sparc64, etc. > You mean you will hide ABI_X86 USE_EXPAND on non-x86 arches, right ? > This would have all the benefits I think, very good idea :) >=20 > Alexis. Shared abi names are bad idea. For example mips abis :=20 o32 n32 n64 eabi x86: x86_32 x86_x32 x86_64 Actualy first three one are equivalent in their internal behavior. But = i dont=20 think that its good idea to have one name for all. Think about multiarc= h=20 installs where you can have binaries from different architectures in on= e=20 system. --=20 Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,=20 Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexxyum@gmail.com mailto:alexxy@gentoo.org mailto:alexxy@omrb.pnpi.spb.ru --nextPart3831615.KVpofZDGor Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

=D0= =92 =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=B5 =D0=BE=D1=82 23 =D1=8F=D0=BD=D0= =B2=D0=B0=D1=80=D1=8F 2013 08:03:56 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE= =D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Alexis Ballier =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0=D0=BB:

>= ; On Wed, 23 Jan 2013 09:24:26 +0100

>= ;

>= ; Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org> wrote:

>= ; > On Mon, 21 Jan 2013 10:27:30 -0300

>= ; >

>= ; > Alexis Ballier <aballier@gentoo.org> wrote:

>= ; > > > To be honest, I don't know if there's other way to hid= e 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=3D"abi1 abi2 abi3"

>= ; > > > MULTILIB_PPC64=3D"abi1 abi2 abi3"

>= ; > > >

>= ; > > > with appropriate USE_EXPAND_HIDDEN set by profiles.

>= ; > >

>= ; > > I don't like that at all.

>= ; > > I'd go for ABI=3D the union of all the MULTILIB_ABIS variab= les (if

>= ; > > there is no name collision)

>= ; > > we certainly want skype to depend on libitneeds[abi_x86], n= ot

>= ; > > 'amd64? ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )'<= /p>

>= ; >

>= ; > Just a quick idea.

>= ; >

>= ; > How would you feel about abi_x86_32? (similarly _64, _x32)

>= ; >

>= ; > That would be almost natural names with the trick variable being=

>= ; > ABI_X86, therefore having all the fore-mentioned advantages.

=

>= ; >

>= ; > The deps would look like:

>= ; > libitneeds[abi_x86_32]

>= ;

>= ; Sounds good too, I just would want it to be shared between arches tha= t

>= ; can: amd64/x86/x32, ppc/ppc64, mips, sparc32/sparc64, etc.

>= ; You mean you will hide ABI_X86 USE_EXPAND on non-x86 arches, right ?<= /p>

>= ; This would have all the benefits I think, very good idea :)

>= ;

>= ; Alexis.

 

Shared abi names are bad i= dea. For example

mips abis :=C2=A0

o32

n32

n64

eabi

x86:

x86_32

x86_x32

x86_64

Actualy first three one ar= e equivalent in their internal behavior. But i dont=C2=A0

think that its good idea t= o have one name for all. Think about multiarch=C2=A0

installs where you can hav= e binaries from different architectures in one=C2=A0

system.

-- =

Bes= t Regards,

Ale= xey 'Alexxy' Shvetsov

Pet= ersburg Nuclear Physics Institute, NRC Kurchatov Institute,

Gat= china, Russia

Dep= artment of Molecular and Radiation Biophysics

Gen= too Team Ru

Gen= too Linux Dev

mai= lto:alexxyum@gmail.com

mai= lto:alexxy@gentoo.org

mai= lto:alexxy@omrb.pnpi.spb.ru

--nextPart3831615.KVpofZDGor-- --nextPart3418030.mxXZTPvBOM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAABCAAGBQJRAB+WAAoJEOf+E+/4L5LmRW8P/Apdp2ZhA3By4GThcqcKkkc4 C1evBIFPEVJN0ijtTKXQcRAzRSbX6XWsyBsNtVrZtLbMY0hnqYOE5M9jCa27NXQX PgB88nBUIc2RnML0doITFSuBTfztCyh/P+A58dirt8jxYvS8BLgZ3gIMuudsG+6f GRMrCohbfJrXJ955/15tHKWyyi73lCRrx1FmnT3RrgwI3csXc0HE2IvJdFhYEfmG 1BRuRc7Aq+ldD25ExXXJfTO5a1vBbcDlqxxL3ZOyuRvWBOyAXrBHhHdXf6dQr8+x pmeTkv8Y/7awGtwv1jZ7EA54gNh4ec9azFAzC2yvYj6WPMZMAtrZd/tRCWswr0pn iDqil7DnfaD5QevNFjjK2PLp6Gqz3Nhkhx6rPsKEsIKAkqe61DfY49yPJ8du+spl soZniz2Y8LgTySLFbUuPx92OyEGls+rXyXD2xcUmDD+bHpi8FCqHfC3oXAMgmvNv wqqQ92c/rbzNl8iCzWKgfrtoUf7CXYjTZ9fzMtC/WpAg7nIkaaCSkE+OF86PXo6L PvTnkKsW0hfm1AUNWbwRHAjucIB1uM7zICKd72p2baxQc3EHv370q9qK2QhwAkWc 8J/hRIBkX9mlCeaw8Sl6Y2TyqKTG+y5Exs3fvNrJeYFvaZ8wbjk/hOawePVZEjiZ LYMx19XYQzdH8nXn62KG =zjun -----END PGP SIGNATURE----- --nextPart3418030.mxXZTPvBOM--