On Tue, Mar 26, 2013 at 4:23 AM, Nick Wellnhofer <[email protected]> wrote:
> * We need a way to compile probes with a temporary set of
> compiler flags.
+1
Charmonizer definitely needs a distinction between flags which are part of the
base set and flags which are part of a probe.
> * Besides appending compiler flags to the "extra" flags, we
> sometimes have to create flags for other purposes. The API
> for both these operations should be easy to use.
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.
> My current implementation is somewhat ad-hoc and I'm not really happy with
> the result. I think it could be cleaned up by introducing a separate "class"
> for compiler flags (and linker flags). It could be used something like that:
>
> chaz_CFlags *flags = chaz_CFlags_new();
> chaz_CFlags_append(flags, "--some-option");
> chaz_CFlags_set_feature_abc(flags, arg1);
> chaz_CFlags_set_feature_xyz(flags, arg2);
> const char *flag_string = chaz_CFlags_get_string(flags);
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.
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.
Marvin Humphrey
