1 |
On Friday 07 July 2006 18:15, Ciaran McCreesh wrote: |
2 |
> On Fri, 7 Jul 2006 18:06:24 -0400 Mike Frysinger <vapier@g.o> |
3 |
> | > The issue with this is that $feature on amd64 is not exactly the |
4 |
> | > same as $feature on x86. Would a better name be ${ARCH}_FEATURES or |
5 |
> | > somesuch? That way there would be no confusion as to whether the |
6 |
> | > cpuflags_sse2 USE flag did something for x86 or for amd64 or for |
7 |
> | > both, since there'd be either x86_features_sse2 or |
8 |
> | > amd64_features_sse2 or both. |
9 |
> | |
10 |
> | it would make handling in ebuilds a bit more complicated |
11 |
> |
12 |
> I'm not so sure. As I understand things based upon previous |
13 |
> discussions on this issue, in most cases fancy optional assembly |
14 |
> routines aren't compatible between x86 and amd64 and separate code is |
15 |
> required for them anyway. |
16 |
|
17 |
where it's a unified configure option it would be: |
18 |
<before> |
19 |
econf $(use_enable mmx) |
20 |
<after> |
21 |
myconf="" |
22 |
use amd64_cpuflags_mmx && myconf="${myconf} --enable-mmx" |
23 |
use x86_cpuflags_mmx && myconf="${myconf} --enable-mmx" |
24 |
econf $myconf |
25 |
|
26 |
then again, the situation we're in now is the same (people either checking |
27 |
USE=mmx or ARCH=amd64, which is wrong imho) |
28 |
|
29 |
> | > It'd also make handling use masking much easier. |
30 |
> | |
31 |
> | why ? because there wouldnt be anything to mask ? |
32 |
> |
33 |
> I'm pretty sure that USE_EXPAND has to be the same across all profiles, |
34 |
> so no, masking would still be required. I'm thinking more avoiding the |
35 |
> cases where amd64 users set CPU_FEATURES="blah", and the fooplayer |
36 |
> package only has blah code written for x86 CPUs. |
37 |
|
38 |
huh ? in your schema, the variable itself would be name spaced, so there |
39 |
would be amd64_CPU_FEATURES, x86_CPU_FEATURES, etc..., there wouldnt be just |
40 |
CPU_FEATURES |
41 |
-mike |