| 1 |
On Friday 07 July 2006 19:43, Ciaran McCreesh wrote: |
| 2 |
> On Fri, 7 Jul 2006 18:36:00 -0400 Mike Frysinger <vapier@g.o> |
| 3 |
> | > | > It'd also make handling use masking much easier. |
| 4 |
> | > | |
| 5 |
> | > | why ? because there wouldnt be anything to mask ? |
| 6 |
> | > |
| 7 |
> | > I'm pretty sure that USE_EXPAND has to be the same across all |
| 8 |
> | > profiles, so no, masking would still be required. I'm thinking more |
| 9 |
> | > avoiding the cases where amd64 users set CPU_FEATURES="blah", and |
| 10 |
> | > the fooplayer package only has blah code written for x86 CPUs. |
| 11 |
> | |
| 12 |
> | huh ? in your schema, the variable itself would be name spaced, so |
| 13 |
> | there would be amd64_CPU_FEATURES, x86_CPU_FEATURES, etc..., there |
| 14 |
> | wouldnt be just CPU_FEATURES |
| 15 |
> |
| 16 |
> My example was demonstrating a problem in the non-namespaced case, not |
| 17 |
> the namespaced solution. Expanding this with an example... |
| 18 |
|
| 19 |
and i was saying in the namespaced solution you wouldnt need to use.mask |
| 20 |
things because $ARCH_CPU_FEATURES would be set by users in the make.conf ... |
| 21 |
if they go setting $WRONGARCH_CPU_FEATURES in make.conf, well i say that's |
| 22 |
their own fault ;) |
| 23 |
-mike |
Archives