On Friday 07 July 2006 18:15, Ciaran McCreesh wrote:
> On Fri, 7 Jul 2006 18:06:24 -0400 Mike Frysinger <[EMAIL PROTECTED]>
> | > The issue with this is that $feature on amd64 is not exactly the
> | > same as $feature on x86. Would a better name be ${ARCH}_FEATURES or
> | > somesuch? That way there would be no confusion as to whether the
> | > cpuflags_sse2 USE flag did something for x86 or for amd64 or for
> | > both, since there'd be either x86_features_sse2 or
> | > amd64_features_sse2 or both.
> |
> | it would make handling in ebuilds a bit more complicated
>
> I'm not so sure. As I understand things based upon previous
> discussions on this issue, in most cases fancy optional assembly
> routines aren't compatible between x86 and amd64 and separate code is
> required for them anyway.
where it's a unified configure option it would be:
<before>
econf $(use_enable mmx)
<after>
myconf=""
use amd64_cpuflags_mmx && myconf="${myconf} --enable-mmx"
use x86_cpuflags_mmx && myconf="${myconf} --enable-mmx"
econf $myconf
then again, the situation we're in now is the same (people either checking
USE=mmx or ARCH=amd64, which is wrong imho)
> | > It'd also make handling use masking much easier.
> |
> | why ? because there wouldnt be anything to mask ?
>
> I'm pretty sure that USE_EXPAND has to be the same across all profiles,
> so no, masking would still be required. I'm thinking more avoiding the
> cases where amd64 users set CPU_FEATURES="blah", and the fooplayer
> package only has blah code written for x86 CPUs.
huh ? in your schema, the variable itself would be name spaced, so there
would be amd64_CPU_FEATURES, x86_CPU_FEATURES, etc..., there wouldnt be just
CPU_FEATURES
-mike
pgpRdcIuR7cXa.pgp
Description: PGP signature
