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