On Fri, Jul 26, 2013 at 10:59 AM, Hans Wennborg <[email protected]> wrote:
> I've been trying to get my head around the rationale behind the option > groups in Options.td. This is how it seems to work currently: > > - Some groups provide HelpText which gets printed by the -help option > > - Some groups provide functionality, i.e. they're actually referenced by > code. For example, the driver will determine its action by looking at the > last option in Action_Group, decide the opt level by last option in > O_Group, etc. > > - Some groups provide functionality by being part of another group. For > example, f_Group doesn't provide any functionality in itself, but it's part > of CompileOnly_Group which is referenced by code. This means we could > s/f_Group/CompileOnly_Group/ without any functionality change. > > - Some groups might have a documentary function. For example, > m_hexagon_features_Group doesn't actually do anything, but it tells the > reader of Optionts.td that options such as -mieee-rnd-near are Hexagon > related. > I think this use case is still really relevant. You could imagine using this to structure a manual page or other generated documentation (maybe even a more rich --help output). This still leaves us with groups with unclear value. For example, the > only purpose of m_Group seems to be to contain all options that start with > 'm'. Or most of them; e.g. -maltivec isn't part of m_Group, and others > might be missing too - we wouldn't notice since the group doesn't have any > real function. > > Should we kill the groups that don't have any function or clear > documentary purpose (the f_Group and m_Group are the big examples here)? > I think we should keep most of these groups, but fix them. Here is a summary of the documentation basis for a bunch of the ones that should stay: f_Group -- compiler "feature" flags. not usually machine-specific, more functionally motivated m_Group -- "machine" flags. should never be seen as generic features, but as hardware and machine level stuff X_Group -- sub-tool flags. -Xclang should be part of this group (and perhaps others) --- These groups I think should go: a_Group -- I have no idea what this is trying to model. L_Group -- I think this was a "language" group, but it doesn't make sense as is. nuke it --- For the groups that remain, I think we should try to fix where have been lax about properly categorizing options into them.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
