On Fri, Nov 18, 2011 at 9:24 AM, Willie Wong <ww...@math.princeton.edu> wrote:
> On Thu, Nov 17, 2011 at 07:41:21PM +0000, James wrote:
>> > Now, why can't the USE descriptions be like the kernel option
>> > descriptions and have something like what Pandu wrote included?
>>
>> I added this to root's .bashrc a long time ago:
>>
>> # USE flag settings hack by Ciaran McCreesh:
>> explainuseflag(){ sed -ne "s,^\([^ ]*:\)\?$1 - ,,p" $(portageq
>> portdir)/profiles/use.{,local.}desc; }
>> alias ef="explainuseflag"
>>
>>
>> Then simply use the alias for a quick check to learn about all the different
>> uses of a given flag:
>>
>> 'ef graphite'
>>
>> # ef graphite
>> Enable support for non-Roman fonts via media-gfx/graphite2
>> Enable support for non-Roman fonts via media-gfx/graphite2
>> Add support for the framework for loop optimizations based on a polyhedral
>> intermediate representation
>>
>> Then drill down into the a specific package's use flag meaning, using the
>> aforementioned 'equery u' delineated by Albert.
>
> You people seem to miss my point. I know perfectly well how to find
> the USE descriptions. It is just that the USE description, in this
> case (as in many others) isn't terribly useful.
>
> "Add support for the framework for loop optimizations based on a
> polyhedral intermediate representation" means absolutely gibberish to
> me.
>
> But if one were to add an additional one or two lines a la Pandu,
> about how it is supposed to make " gcc-4.5.3 use a newer method to
> detect parallelism, thus (potentially) makes programs compiled by gcc
> to have better multithreaded performance"
Pretty sure having the word 'optimizations' is sufficient for that.
The rest, you can look up. (Sorry, I hate "Just google it" answers
more than most, but I think it's appropriate in this case)
IMO, USE flags should have good meaning to people familiar with the
field the package is related to. Otherwise, to keep the same terse
length, you have to "dumb it down"...but how far do you go?
Now, in this case, I think the use of the word 'polyhedral' in the
description is just silly; that's not going to mean anything to anyone
not intimately familiar with compiler optimizations, if not intimately
familiar with graphite itself. It should probably read something more
like "Add support for the experimental 'graphite' framework for loop
optimizations."
If I read his email correctly, Pandu indicated that multithreaded
environments are an example of the impact the new optimization engine
may have. I don't think he indicated that that was its specific
function, so I wouldn't go so far as to point out multithreaded
environments in the USE flag description.
> and perhaps even a Kernel
> help page style "It is mostly stable. If unsure, say Yes."
I'm pretty sure that's the purpose of the default state of USE flags;
if it's enabled by default, it's "if unsure, say Yes." If it's
disabled by default, it's "if unsure, say No."
> It would be ever so much more helpful for people who would like to
> find out what new flags do before deciding whether or not to follow
> the default recommended by the devs which are set into the profile.
Honestly, if you don't know (and I didn't), the best option seems to
me to be to ask a similar question to what Stéphane asked. Perhaps
"what does the 'graphite' USE flag for gcc add?", but go on to say, "I
see the USE flag description is '...', but what's the result?"
>
> (I'm not saying this type of hand holding is necessary for all flags:
> "enable support for non-Roman fonts via media-gfx/graphite2" is
> perfectly understandable, as are most other flags about features a
> "user" is likely to interact with. But for some of the more "system"
> type flags (see also that python/perl flag business from the recent
> months), I think the USE descriptions can stand some improvement.)
Sure. The problem is, what constitutes an improvement for each case?
(And perhaps it'd be a good idea to file bug reports against the
ebuilds.)
IIRC, the recent 'perl' USE flag kerfluffle was about removing 'perl'
support dropping tabs in an application, when those tabs were made
possible by a particular Perl script. I doubt that was the only
perl-based extension, but the argument made at the time was that the
USE flag that affected Perl support for the app should specifically
invoke that it affected that extensions.
That's like saying that a 'perl' or 'extensions' USE flag for irssi
should talk about disabling nick highlighting, when it would also
affect named windows, presence notifications...*anything* that depends
on its Perl extensions mechanism.
--
:wq
