[lucy-dev] Charmonizer compiler flags

[Nick Wellnhofer <we...@aevum.de>]

Hello lucy-dev,

In the course of my work on the C bindings, I had to add functions to 
Charmonizer::Core::Compiler that handle several flags needed to compile 
and link the shared library. Also, some additional requirements popped up:

     * We need a way to compile probes with a temporary set of
       compiler flags.
     * 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.

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);

Then the chaz_CC struct would have the following fields with 
corresponding accessors:

     chaz_CFlags *extra_cflags;
     chaz_CFlags *temp_cflags;

Using temporary flags would work like this:

     chaz_CFlags *temp_flags = chaz_CC_get_temp_cflags();
     chaz_CFlags_append(temp_flags, "--option");
     chaz_CC_test_compile(...);
     chaz_CFlags_clear(temp_flags);

What do you think?

Nick

Re: [lucy-dev] Charmonizer compiler flags

[Nick Wellnhofer <we...@aevum.de>]

On Mar 27, 2013, at 02:36 , Marvin Humphrey <ma...@rectangular.com> 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
 

Re: [lucy-dev] Charmonizer compiler flags

[Marvin Humphrey <ma...@rectangular.com>]

On Tue, Mar 26, 2013 at 4:23 AM, Nick Wellnhofer <we...@aevum.de> 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

Re: [lucy-dev] Charmonizer compiler flags

[Peter Karman <pe...@peknet.com>]

Nick Wellnhofer wrote on 3/26/13 6:23 AM:

> 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);
> 
> Then the chaz_CC struct would have the following fields with corresponding
> accessors:
> 
>     chaz_CFlags *extra_cflags;
>     chaz_CFlags *temp_cflags;
> 
> Using temporary flags would work like this:
> 
>     chaz_CFlags *temp_flags = chaz_CC_get_temp_cflags();
>     chaz_CFlags_append(temp_flags, "--option");
>     chaz_CC_test_compile(...);
>     chaz_CFlags_clear(temp_flags);
> 
> What do you think?

+1


-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com