From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RRQ1X-0000eP-Pd for garchives@archives.gentoo.org; Fri, 18 Nov 2011 15:06:40 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 75D0421C105; Fri, 18 Nov 2011 15:06:30 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) by pigeon.gentoo.org (Postfix) with ESMTP id 95B2E21C078 for ; Fri, 18 Nov 2011 15:05:37 +0000 (UTC) Received: from mail-fx0-f53.google.com ([209.85.161.53]) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1RRQ0Y-001ZWF-Qq for gentoo-user@lists.gentoo.org; Fri, 18 Nov 2011 22:05:39 +0700 Received: by faan15 with SMTP id n15so5263527faa.40 for ; Fri, 18 Nov 2011 07:05:32 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.13.70 with SMTP id b6mr3826300bka.78.1321628732492; Fri, 18 Nov 2011 07:05:32 -0800 (PST) Received: by 10.223.74.16 with HTTP; Fri, 18 Nov 2011 07:05:32 -0800 (PST) Received: by 10.223.74.16 with HTTP; Fri, 18 Nov 2011 07:05:32 -0800 (PST) In-Reply-To: <20111118142404.GA21198@math.princeton.edu> References: <4EC2B642.3010500@gmail.com> <201111160811.17331.stephane@22decembre.eu> <20111116133052.GA12194@math.princeton.edu> <20111118142404.GA21198@math.princeton.edu> Date: Fri, 18 Nov 2011 22:05:32 +0700 Message-ID: Subject: Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed? From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=00151750da4a200cc104b203ab0b X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Archives-Salt: 1d960677-254c-4641-a391-33ffa5fd788a X-Archives-Hash: 053c57e308387376767d12f90db227b0 --00151750da4a200cc104b203ab0b Content-Type: text/plain; charset=UTF-8 On Nov 18, 2011 9:27 PM, "Willie Wong" 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" and perhaps even a Kernel > help page style "It is mostly stable. If unsure, say Yes." > > 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. > > (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.) > I agree with you (and not because my name is mentioned :-P). I got lucky with USE "graphite": gcc's homepage is quite clear; a 15-minute reading convinced me to try graphite. But there are still lots of other USE flags that sent me on hours of goose-chase before I can enable/disable with conviction. I'm not sure where to put the more detailed explanations, though; perhaps a $PN.usedesc file in the package's directory? Kind of a complement to the .ebuild file(s). Rgds, --00151750da4a200cc104b203ab0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Nov 18, 2011 9:27 PM, "Willie Wong" <wwong@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 o= ption
> > > descriptions and have something like what Pandu wrote includ= ed?
> >
> > I added this to root's =C2=A0.bashrc a long time ago:
> >
> > # USE flag settings hack by Ciaran McCreesh:
> > explainuseflag(){ sed -ne "s,^\([^ ]*:\)\?$1 - ,,p" $(p= ortageq
> > portdir)/profiles/use.{,local.}desc; }
> > alias ef=3D"explainuseflag"
> >
> >
> > Then simply use the alias for a quick check to learn about all th= e 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 p= olyhedral
> > intermediate representation
> >
> > Then drill down into the a specific package's use flag meanin= g, 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<= br> > polyhedral intermediate representation" means absolutely gibberis= h 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 t= o
> detect parallelism, thus (potentially) makes programs compiled by gcc<= br> > to have better multithreaded performance" and perhaps even a Kern= el
> help page style "It is mostly stable. If unsure, say Yes." >
> 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. >
> (I'm not saying this type of hand holding is necessary for all fla= gs:
> "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.)
>

I agree with you (and not because my name is mentioned :-P).

I got lucky with USE "graphite": gcc's homepage is quite c= lear; a 15-minute reading convinced me to try graphite. But there are still= lots of other USE flags that sent me on hours of goose-chase before I can = enable/disable with conviction.

I'm not sure where to put the more detailed explanations, though; pe= rhaps a $PN.usedesc file in the package's directory? Kind of a compleme= nt to the .ebuild file(s).

Rgds,

--00151750da4a200cc104b203ab0b--