From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1FyYNb-0006hR-2C for garchives@archives.gentoo.org; Thu, 06 Jul 2006 18:15:11 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k66IC6D8012988; Thu, 6 Jul 2006 18:12:06 GMT Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k66I7DW4022045 for ; Thu, 6 Jul 2006 18:07:13 GMT Received: by nf-out-0910.google.com with SMTP id a4so77120nfc for ; Thu, 06 Jul 2006 11:07:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:x-face:mime-version:content-type:content-transfer-encoding:message-id:sender; b=uSFL5fpz4ruWaOAKzH31KofUUA28N3uXm0cmqufxBb8R/fLNoWoJUdghQzLemSGymYGB5czlwJX99wHwUFRzAxNFlKt0Vm0fimxwDMisWQpfi8OC2/EAwnqkg3S3/+huZDh3Z85psZslby0anzVET7ZcRbg+Blotkcl2e9Hf3Eo= Received: by 10.48.47.3 with SMTP id u3mr654525nfu; Thu, 06 Jul 2006 11:07:12 -0700 (PDT) Received: from enterprise.flameeyes.is-a-geek.org ( [151.56.118.124]) by mx.gmail.com with ESMTP id n22sm8431622nfc.2006.07.06.11.07.11; Thu, 06 Jul 2006 11:07:12 -0700 (PDT) From: "Diego 'Flameeyes' =?utf-8?q?Petten=C3=B2?=" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Replacing cpu-feature USE flags Date: Thu, 6 Jul 2006 20:07:00 +0200 User-Agent: KMail/1.9.3 References: <200607061252.33028@enterprise.flameeyes.is-a-geek.org> <200607061843.16899@enterprise.flameeyes.is-a-geek.org> <20060706185110.46f234ce@snowdrop.home> In-Reply-To: <20060706185110.46f234ce@snowdrop.home> X-Face: +=-v@W}H`=.Bn2t&97Un7{[.c0aP0"8)JI?7Z?E>l>ZNY|,=?utf-8?q?mL=5C3bs=0A=09xW=23jRz=7CVa=5C?=@NIS3-'W[F.^YLqK=rS:D*Ke`Y5giI@$(xIBQ<0i740;wuI{lYd>>=?utf-8?q?eFVDuAr=0A=09=3Br=5B*=7E/zd=604dEI?= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1764893.74LHimGNjM"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200607062007.00422@enterprise.flameeyes.is-a-geek.org> Sender: "=?UTF-8?Q?Diego=20\"Flameeyes\"=20Petten=C3=B2?=" X-Archives-Salt: 5a2693ae-682b-47fc-b702-4fb8607a46b6 X-Archives-Hash: 197619d630d21d42c313a41f37a7ab55 --nextPart1764893.74LHimGNjM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 06 July 2006 19:51, Ciaran McCreesh wrote: > And for a single compile? I always leave the two of them in sync, even C++ apps might have parts=20 building CFLAGS. In case you know you're going to use only C++ is not=20 difficult to use CFLAGS=3D${CXXFLAGS} has_cpuset 3dnow don't you think? > And your assumption would be wrong. I can assure you that relying upon > -march doing anything sensible with __MAGIC__ is entirely unsafe. Go > and look at the VIS handling if you want a perfect example. Okay, maybe VIS handling is broken. But we can rely pretty safely on x86,=20 amd64 and PPC gcc to know the table of arches and extensions supported.=20 Remember that I asked to talk with SPARC team for VIS just because I only=20 know about the other three arches. > No no. Where "regain control" means the user has to screw around with > nasty hacks and pray, rather than setting a well defined, specific > variable. =46ind me a reason to do that, a part for broken MMX code that should be=20 disabled on the ebuild itself already. > Uh. USE flags are available at DEPEND time. If you talk about the nasm dependency, then it is rare, most of the MMX=20 support is inline in C sources anyway. > And at the metadata phase? Should be already transparent or something is strange. nasm is simpler to a= dd=20 the dependency for x86, there is really few people not enabling mmx already= =2E=20 Yes it is a bit of regression, but for a small percentage of users, while=20 there's more safety for many other people. > Er. No. Not at all. The __MAGIC__ isn't guaranteed. Quite the contrary. This ain't no magic. The magic is in the _CODE_ that GCC creates, but not i= n=20 the _DEFINES_ that GCC emits. > You're trying to guess what the user wants based upon hairy magic, No, about their chosen architecture. > rather than doing what the user says (aren't you always yelling at > upstreams for doing that?) The user asks for athlon64 support? They get athlon64 (mmx, 3dnow, 3dnowex,= =20 sse, sse2) The user asks for G3 support? They get G3 (nothing) The user asks for Pentium4 support? They get what they want (mmx, sse, sse2= ,=20 sse3 in case) =2D-=20 Diego "Flameeyes" Petten=C3=B2 - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE --nextPart1764893.74LHimGNjM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQBErVFEe2h1+2mHVWMRAr1tAKCOlk0aERq9ALuRdByUYjW78LN9NQCgiFWN x4NyeBqOx/S3AFYkvPm5k68= =d2VS -----END PGP SIGNATURE----- --nextPart1764893.74LHimGNjM-- -- gentoo-dev@gentoo.org mailing list