On 31 August 2012 17:25, Ollie Wild <a...@google.com> wrote: > > On Fri, Aug 31, 2012 at 10:01 AM, Simon Baldwin <sim...@google.com> wrote: > > On 31 August 2012 16:31, Ollie Wild <a...@google.com> wrote: > >> > > > > The patch exactly meets the definition of google/integration only, > > which is that it fixes up something that affects only Google's use of > > gcc. > > The criterion is more subtle than that. The google/integration branch > is for things which: (a) cannot be submitted to trunk, and (b) are > required for inter-operability with our build/test systems. The goal > is to keep any changes relative to trunk as minimal as possible, and > frankly, much of the stuff that's there now should be cleaned up and > submitted upstream. > > > --no-canonical-prefixes is similar. That too is only in our > > branches and not in trunk, for the same reason. > > But -no-canonical-prefixes *is* in trunk. Presumably the same people > who benefit from that will also benefit from this. In fact, I think a > reasonable case could be made that header canonicalization should be > gated on the same flag.
Yes. I meant --disable-canonical-prefixes. That is a gcc configure flag that we use to control the default setting for -[no-]canonical-prefixes where neither flag is supplied on the gcc command line. --disable/enable-canonical-prefixes is only in google branches. > > > > > I'd rather keep this out of trunk unless there are known external use > > cases where it's beneficial. That keeps both the review and the > > testing load to acceptable -- though still extremely high -- levels. > > The same argument could be made about *any* patch we submit. Pushing > upstream is always more work, but if we don't do it, we end up paying > for it later. Not at all. An ICE that only occurred with Google code as gcc input is a perfect counterexample. -- Google UK Limited | Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ | Registered in England Number: 3977902
