clang-cc option change

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

clang-cc option change

Daniel Dunbar
Hi all,

As part of clang / clang-cc integration, I am about to switch clang-cc
to using the new option parsing functionality, and drop the use of
llvm::cl.

This has a few implication you might want to be aware of:
 1. The exact syntax accepted by clang-cc is becoming much stricter,
and follows the clang (slash gcc driver) argument format. The most
noticeable differences:
    a. '-a' cannot automatically be spelled '--a'; if this is desired
it must be explicit in the CC1Options.td file (using an alias).
    b. Options which take arguments don't automatically accept the
'-foo=bar', and this form is never allowed for boolean options. Some
options are still allowed to be spelled as either '-foo bar' or
'-foo=bar', but only because explicit aliases have been defined for
them.

If this fundamentally upsets you, we could change it by making the
option parser more flexible. However, given that this matches how the
driver works, it makes sense to me to have clang and clang -cc1 behave
similarly.

 2. Adding options is now totally different, and unfortunately a bit
more cumbersome. I hope to make it less cumbersome over time, but
until then feel free to swear at me under your breath when you go to
add an option. The reason it is more cumbersome is because we have
more functionality, namely the ability to serialize and deserialize a
CompilerInvocation object to an argument vector.

Previously, adding an option to clang-cc generally meant:
 a. Add an entry in LangOptions or CodeGenOptions or whatever to
persist the value.
 b. Add an llvm::cl option definition.
 c. Add some code in clang-cc.cpp (that code is now in Options.cpp) to
take the llvm::cl value and stuff it into the field from (a).

Now, adding an option to clang-cc (soon to be clang -cc1) looks like:
 a. (same as above)
 b. Add the option in include/clang/Driver/CC1Options.td
 c. Add code to serialize the option in CompilerInvocation.cpp in the
appropriate ParseFooArgs routine. That is, given a LangOptions
structure, create the necessary command line arguments to regenerate
the field. Generally this forces options to be simpler and more
consistent -- if you require some logic be associated with your option
then that logic should be in the Driver, not in clang-cc.
 d. Add code to parse/deserialize the field from an argument vector,
in the appropriate FooToArgs routine. Note that the OptParser library
currently has less support for, say, interpreting enums, than llvm::cl
which is one of the reasons this can be cumbersome.

My eventual hope is to leverage the CC1Options.td file more so that
the serialization / deserialization code is more automatic (and
validated). The idea would be to keep the option definitions separate,
but provide additional information on how they should be mapped onto a
C++ structure. This might also be useful for defining parts of how the
Driver maps command line arguments to Tools.

 - Daniel
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: clang-cc option change

Daniel Dunbar
An extra point I forgot to make, this also implies that clang-cc no
longer accepts llvm::cl options. I will add -mllvm if there proves to
be a need, but I also plan to fight against it. :)

 - Daniel

On Wed, Dec 2, 2009 at 8:10 PM, Daniel Dunbar <[hidden email]> wrote:

> Hi all,
>
> As part of clang / clang-cc integration, I am about to switch clang-cc
> to using the new option parsing functionality, and drop the use of
> llvm::cl.
>
> This has a few implication you might want to be aware of:
>  1. The exact syntax accepted by clang-cc is becoming much stricter,
> and follows the clang (slash gcc driver) argument format. The most
> noticeable differences:
>    a. '-a' cannot automatically be spelled '--a'; if this is desired
> it must be explicit in the CC1Options.td file (using an alias).
>    b. Options which take arguments don't automatically accept the
> '-foo=bar', and this form is never allowed for boolean options. Some
> options are still allowed to be spelled as either '-foo bar' or
> '-foo=bar', but only because explicit aliases have been defined for
> them.
>
> If this fundamentally upsets you, we could change it by making the
> option parser more flexible. However, given that this matches how the
> driver works, it makes sense to me to have clang and clang -cc1 behave
> similarly.
>
>  2. Adding options is now totally different, and unfortunately a bit
> more cumbersome. I hope to make it less cumbersome over time, but
> until then feel free to swear at me under your breath when you go to
> add an option. The reason it is more cumbersome is because we have
> more functionality, namely the ability to serialize and deserialize a
> CompilerInvocation object to an argument vector.
>
> Previously, adding an option to clang-cc generally meant:
>  a. Add an entry in LangOptions or CodeGenOptions or whatever to
> persist the value.
>  b. Add an llvm::cl option definition.
>  c. Add some code in clang-cc.cpp (that code is now in Options.cpp) to
> take the llvm::cl value and stuff it into the field from (a).
>
> Now, adding an option to clang-cc (soon to be clang -cc1) looks like:
>  a. (same as above)
>  b. Add the option in include/clang/Driver/CC1Options.td
>  c. Add code to serialize the option in CompilerInvocation.cpp in the
> appropriate ParseFooArgs routine. That is, given a LangOptions
> structure, create the necessary command line arguments to regenerate
> the field. Generally this forces options to be simpler and more
> consistent -- if you require some logic be associated with your option
> then that logic should be in the Driver, not in clang-cc.
>  d. Add code to parse/deserialize the field from an argument vector,
> in the appropriate FooToArgs routine. Note that the OptParser library
> currently has less support for, say, interpreting enums, than llvm::cl
> which is one of the reasons this can be cumbersome.
>
> My eventual hope is to leverage the CC1Options.td file more so that
> the serialization / deserialization code is more automatic (and
> validated). The idea would be to keep the option definitions separate,
> but provide additional information on how they should be mapped onto a
> C++ structure. This might also be useful for defining parts of how the
> Driver maps command line arguments to Tools.
>
>  - Daniel
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Loading...