1 |
On Fri, Nov 18, 2011 at 9:24 AM, Willie Wong <wwong@××××××××××××××.edu> wrote: |
2 |
> On Thu, Nov 17, 2011 at 07:41:21PM +0000, James wrote: |
3 |
>> > Now, why can't the USE descriptions be like the kernel option |
4 |
>> > descriptions and have something like what Pandu wrote included? |
5 |
>> |
6 |
>> I added this to root's .bashrc a long time ago: |
7 |
>> |
8 |
>> # USE flag settings hack by Ciaran McCreesh: |
9 |
>> explainuseflag(){ sed -ne "s,^\([^ ]*:\)\?$1 - ,,p" $(portageq |
10 |
>> portdir)/profiles/use.{,local.}desc; } |
11 |
>> alias ef="explainuseflag" |
12 |
>> |
13 |
>> |
14 |
>> Then simply use the alias for a quick check to learn about all the different |
15 |
>> uses of a given flag: |
16 |
>> |
17 |
>> 'ef graphite' |
18 |
>> |
19 |
>> # ef graphite |
20 |
>> Enable support for non-Roman fonts via media-gfx/graphite2 |
21 |
>> Enable support for non-Roman fonts via media-gfx/graphite2 |
22 |
>> Add support for the framework for loop optimizations based on a polyhedral |
23 |
>> intermediate representation |
24 |
>> |
25 |
>> Then drill down into the a specific package's use flag meaning, using the |
26 |
>> aforementioned 'equery u' delineated by Albert. |
27 |
> |
28 |
> You people seem to miss my point. I know perfectly well how to find |
29 |
> the USE descriptions. It is just that the USE description, in this |
30 |
> case (as in many others) isn't terribly useful. |
31 |
> |
32 |
> "Add support for the framework for loop optimizations based on a |
33 |
> polyhedral intermediate representation" means absolutely gibberish to |
34 |
> me. |
35 |
> |
36 |
> But if one were to add an additional one or two lines a la Pandu, |
37 |
> about how it is supposed to make " gcc-4.5.3 use a newer method to |
38 |
> detect parallelism, thus (potentially) makes programs compiled by gcc |
39 |
> to have better multithreaded performance" |
40 |
|
41 |
Pretty sure having the word 'optimizations' is sufficient for that. |
42 |
The rest, you can look up. (Sorry, I hate "Just google it" answers |
43 |
more than most, but I think it's appropriate in this case) |
44 |
|
45 |
IMO, USE flags should have good meaning to people familiar with the |
46 |
field the package is related to. Otherwise, to keep the same terse |
47 |
length, you have to "dumb it down"...but how far do you go? |
48 |
|
49 |
Now, in this case, I think the use of the word 'polyhedral' in the |
50 |
description is just silly; that's not going to mean anything to anyone |
51 |
not intimately familiar with compiler optimizations, if not intimately |
52 |
familiar with graphite itself. It should probably read something more |
53 |
like "Add support for the experimental 'graphite' framework for loop |
54 |
optimizations." |
55 |
|
56 |
If I read his email correctly, Pandu indicated that multithreaded |
57 |
environments are an example of the impact the new optimization engine |
58 |
may have. I don't think he indicated that that was its specific |
59 |
function, so I wouldn't go so far as to point out multithreaded |
60 |
environments in the USE flag description. |
61 |
|
62 |
> and perhaps even a Kernel |
63 |
> help page style "It is mostly stable. If unsure, say Yes." |
64 |
|
65 |
I'm pretty sure that's the purpose of the default state of USE flags; |
66 |
if it's enabled by default, it's "if unsure, say Yes." If it's |
67 |
disabled by default, it's "if unsure, say No." |
68 |
|
69 |
> It would be ever so much more helpful for people who would like to |
70 |
> find out what new flags do before deciding whether or not to follow |
71 |
> the default recommended by the devs which are set into the profile. |
72 |
|
73 |
Honestly, if you don't know (and I didn't), the best option seems to |
74 |
me to be to ask a similar question to what Stéphane asked. Perhaps |
75 |
"what does the 'graphite' USE flag for gcc add?", but go on to say, "I |
76 |
see the USE flag description is '...', but what's the result?" |
77 |
|
78 |
> |
79 |
> (I'm not saying this type of hand holding is necessary for all flags: |
80 |
> "enable support for non-Roman fonts via media-gfx/graphite2" is |
81 |
> perfectly understandable, as are most other flags about features a |
82 |
> "user" is likely to interact with. But for some of the more "system" |
83 |
> type flags (see also that python/perl flag business from the recent |
84 |
> months), I think the USE descriptions can stand some improvement.) |
85 |
|
86 |
Sure. The problem is, what constitutes an improvement for each case? |
87 |
(And perhaps it'd be a good idea to file bug reports against the |
88 |
ebuilds.) |
89 |
|
90 |
IIRC, the recent 'perl' USE flag kerfluffle was about removing 'perl' |
91 |
support dropping tabs in an application, when those tabs were made |
92 |
possible by a particular Perl script. I doubt that was the only |
93 |
perl-based extension, but the argument made at the time was that the |
94 |
USE flag that affected Perl support for the app should specifically |
95 |
invoke that it affected that extensions. |
96 |
|
97 |
That's like saying that a 'perl' or 'extensions' USE flag for irssi |
98 |
should talk about disabling nick highlighting, when it would also |
99 |
affect named windows, presence notifications...*anything* that depends |
100 |
on its Perl extensions mechanism. |
101 |
|
102 |
-- |
103 |
:wq |