On Mar 27, 2013, at 02:36 , Marvin Humphrey <[email protected]> wrote:
> We may need a few more features down the road:
>
> * extract option name from flag string
> * inspect option values
> * set option values
> * specify options by concrete flag name (`-O`)
> * specify options by abstract feature ("optimization")
> * differentiate between flags which may appear multiple times and flags
> which may appear only once
>
> Consider the following scenario: `charmonize` is passed a set of flags which
> includes `-O3`, but we want to disable optimization for the sake of a
> particular probe.
That would be nice but parsing compiler flags sounds rather complicated.
> My first question would be whether we need to represent individual flags using
> individual `chaz_CCOption` objects. Is it too soon to go that route? We can
> always do it later.
I don't really need these features at the moment.
> Regardless, it seems like a good idea to abstract flag handling out of
> Compiler and into a dedicated module, since Compiler has a lot going on.
I implemented the proposed changes in a new branch 'chaz-cflags'. I think it's
nicer than what we had before and it should be a good basis for more involved
handling of compiler flags.
Nick
