On 11 March 2015 at 21:27, Chandler Carruth <[email protected]> wrote: > We should have a single unambiguous spelling for long options in the absence > of compatibility concerns with other tools.
+1 > The vastly more common prefix for these in the rest of the world is '--'. > LLVM's usage of '-' is quite strange. +1 > I also think there is a strong technical reason to require the '=' -- it > makes the relative ordering unimportant. For any tool (such as a build > system) which builds up commandline flags, this is a huge advantage. +2! > I don't know that we need some formal document of this kind, but if you'd > like to propose a patch for the clang internals documentation, that would be > nice. The issue is that compatibility is a bit vague. For instance, gcc has -mcpu=foo which is against the "agreed standard" for optargs. Not that it's invalid, just that the Unix world kind of agreed that the two accepted syntaxes are "-a opt" and "--a=opt" and not the other two. So, does "compatibility" means "only the ones that other tools have specifically" (such as -mcpu), or "similar to what other tools have" (such as -target)? If the former, than I suggest we use the compatibility layer to convert "legacy" options into standard ones. So, "--target=foo", "--mcpu=bar" are the standard and "-target foo" and "-mcpu=bar" are accepted as legacy options. If the latter, than accepting all options for all choices is the only way to keep everyone happy. I vote for the first, but too many people seem to prefer the second. cheers, --renato _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
