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 A413913862F for ; Wed, 23 Jan 2013 18:48:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8989021C0E8; Wed, 23 Jan 2013 18:48:25 +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 79CF721C00C for ; Wed, 23 Jan 2013 18:48:24 +0000 (UTC) Received: from localhost (unknown [200.89.69.133]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 5C5AE33D3DA; Wed, 23 Jan 2013 18:48:22 +0000 (UTC) Date: Wed, 23 Jan 2013 15:48:12 -0300 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Cc: alexxy@gentoo.org Subject: Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib Message-ID: <20130123154812.6ae04e15@gentoo.org> In-Reply-To: <1379020.gIisfkuREL@x230i> References: <20130120201131.5afcbf48@pomiocik.lan> <20130123092426.56745d6b@pomiocik.lan> <20130123080356.11ee5f6a@gentoo.org> <1379020.gIisfkuREL@x230i> Organization: Gentoo X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.14; 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: a3f4e7b9-5cd3-4f78-ba7a-5ac05eb98737 X-Archives-Hash: 709d8466fa52d191f8943b56c36790bd On Wed, 23 Jan 2013 21:36:22 +0400 Alexey Shvetsov wrote: > =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 > > > > > flags 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 (if > > > > 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 > > that 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. >=20 > Shared abi names are bad idea. For example > mips abis :=20 > o32 > n32 > n64 > eabi > x86: > x86_32 > x86_x32 > x86_64 >=20 > Actualy first three one are equivalent in their internal behavior. > But i dont think that its good idea to have one name for all. Sorry, I don't get it. What was meant here was one USE_EXPAND variable per group of similar arches. Different abis are, of course, distinguished within each variable. > Think > about multiarch installs where you can have binaries from different > architectures in one system. It depends what we want through multilib. I personally think multiarch is out of scope: there is crossdev for that. Alexis.