1 |
Christopher Head <chead@×××××.ca> wrote: |
2 |
> |
3 |
> All that requires is knowing the names, though; it would be |
4 |
> fine if no package actually uses the feature yet. |
5 |
|
6 |
++ |
7 |
|
8 |
More precisely: When changing the names anyway, |
9 |
IMHO it would be a very good idea to follow the convention of the |
10 |
"flag" names in /proc/cpuinfo and add all flags supported |
11 |
there as possible USE-flags, no matter, whether they are currently |
12 |
used in some package or not. |
13 |
The list might still be extended when a new processor with new features |
14 |
comes out. |
15 |
|
16 |
If this is done properly, the user could easily write a script to set |
17 |
these flags appropriate for his current machine. One might even give |
18 |
portage a "--use-native" switch (or FEATURE=use-native) |
19 |
which sets the USE defaults corresponding to the current |
20 |
/proc/cpuinfo output. The latter is what typical desktop users |
21 |
probably would prefer: A complete analogue of CFLAGS=-march=native; |
22 |
just generating optimal code for his machine, without requiring |
23 |
the user to understand all the fancy details of his processor. |
24 |
|
25 |
To properly support packages which can choose the appropriate code |
26 |
at runtime, I suggest to add in addition an "all" flag which just |
27 |
compiles in all possible optimized code-paths. |