<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 25, 2013 at 9:46 AM, Hans Wennborg <span dir="ltr"><<a href="mailto:hans@chromium.org" target="_blank" class="cremed">hans@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">  > Second, a lot of my comments below are along the lines of "fix the grouping of options we have to be rational, and then use that to do the CL-opt-in". I think this is really important to make sure we get it right. I suggest doing it now because I think it'll be fairly easy to do. If something explodes into a lot of work, push back! =] I'm happy to convert really hard stuff here to FIXMEs as long as you eventually fix them.<br>

<br>
</div>  I think this is the big ticket item here. I'm not sure if by grouping you mean changing the Group (f_Group, etc.) on the options, or you mean how they are actually ordered in the file, or both.<br></blockquote>
<div><br></div><div>I'm not talking about how they are ordered in the file -- although feel free to re-order things in a way that helps make the file more readable.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
  I think the Group classes might be orthogonal to what we're trying to do here. They're good for categorizing whether something is a debug or a warning related option, etc., so that such options can be handled in one place, but I don't think they would work for excluding or including options in cl-mode vs gcc-mode. An option can only be in one Group (which can, I think, be part of a larger Group), so we couldn't have options be part of both a group_Debug and group_CL.<br>

<br>
  Flags are good for that, because they can cut across groups. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  I think reordering the options into "clang options, gcc compat options, cl compat options, cc1 internal options" like you suggest in the comment below sounds great. We should then be able to put flags on the options in a straight-forward way (CLCompat, GCCComap, CC1Option) based on that ordering.</blockquote>
</div><div class="gmail_extra"><br></div>I completely agree that flags are the way to organize what set the options go into. =] We're on the same page there.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
What I'm trying to say about groups is that currently, the hierarchical structure of the groups is both coarse and not thought out very well. I'm suggesting that there are specific, hierarchy forming (and thus compatible with the 1-group-only requirement), changes to the group which would subsequently allow us to quickly automated the application of flags to many of the options. For example, if we have a specific group for the diagnostic message controlling 'f' flags, we could immediately opt those into the clang options flag.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">None of this should obviate the need to do some special marking of options with a flag, but my hope is that it greatly reduces the number of them, and lessens the maintenance burden of keeping things in sync.</div>
</div>