Add -Wc,<arg> option (similar to -Wl,<arg>) to go along with -Xclang. This makes it easier to pass multiple options to cc1.
Details
Diff Detail
Event Timeline
Hi Joerg:
This change would allow users to pass multiple options, or options with
arguments, to cc1 without having to use -Xclang multiple times.
Recently, the -load option was added, at least partly, because passing
-Xclang multiple times was cumbersome. (I like that change btw)
Had -Wc, been available, perhaps that wouldn't have been that much of an
issue.
But I'll defer to your better judgement on this -- I certainly wouldn't
advocate an explosion of new options.
Thanks for concidering it...
Don
Here are a few examples from existing tests showing how this option could be used:
-Xclang -analyzer-max-loop -Xclang 34
becomes:
-Wc,-analyzer-max-loop,34
-Xclang -analyzer-checker=debug.ConfigDumper -Xclang -analyzer-max-loop -Xclang 34
becomes:
-Wc,-analyzer-checker,debug.ConfigDumper,-analyzer-max-loop,34
-Xclang -analyzer-config -Xclang path-diagnostics-alternate=true -Xclang -analyzer-output=plist
becomes:
-Wc,-analyzer-config,path-diagnostics-alternate=true,-analyzer-output=plist
-Xclang -internal-isystem -Xclang /tmp/
becomes:
-Wc,-internal-isystem,/tmp/
-Xclang -internal-externc-isystem -Xclang /tmp
becomes:
-Wc,-internal-externc-isystem,/tmp
-Xclang -main-file-name -Xclang foo.c
becomes:
-Wc,-main-file-name,foo.c
-Xclang -include-pch -Xclang %t.pch
becomes:
-Wc,-include-pch,%t.pch
-Xclang -fdisable-module-hash -Xclang -detailed-preprocessing-record -Xclang -verify
becomes:
-Wc,-fdisable-module-hash,-detailed-preprocessing-record,-verify
While I can certainly appreciate the simplification this may afford, Im not sure if adding a new option here is really that valuable. Options being added to the frontend are expensive because they can't be changed or removed. If gcc has a similar frontend option, we may consider it for compatibility (as was the case for -fplugin). In this case, yes, it is harder to type options that we are passing down, but they are backend options and not meant to be used by users in the general case. The -Xclang and -mllvm options currently are available, and make it clear enough where the option is going. Arguably this is a bad idea since it makes it easier to pull backend options into the frontend. Is there a stronger reason for this other than aesthetics?
Mainly aesthetic. It was the only one of the group, -Xassembler, -Xlinker, -Xpreprocessor, and -Xclang, that didn't have a corresponding comma separated option, so I figured it might be a good addition.
Ah. Well, Im tempted to say that we should avoid the option. Generally, making the backend options visible is undesirable since there is no guarantee of stability there. This simplifies that, and if users start using that, we would not be able to change those as easily.
Wasn't an unreasonable thought though :-).