Re: Put compile options from code into parse_transform/2 options variable

I have done a few things in this area:

When using the parse_trans transform functions, you can provide an option, either as a compile attribute in the code or added as an option to compile, to save a pretty-printed result or simply write the resulting forms to a file:

https://github.com/uwiger/parse_trans/blob/master/src/parse_trans.erl#L397

I haven’t exported parse_trans:option_value/3, but it’s fairly simple:
https://github.com/uwiger/parse_trans/blob/master/src/parse_trans.erl#L457

In another project, I played around with Igor for module inlining. Igor takes some options, which makes it awkward to use directly as a parse transform, so I wrote a wrapper:

https://github.com/Feuerlabs/exometer/blob/master/src/exometer_igor.erl

BR,
Ulf W

On 01 May 2014, at 19:47, Enrique Fernández Casado <[email protected]> wrote:

> AFAIK, there is no way to specify per-transform options. So 
> all four compile options will end up in the "options" variable
> of the two specified parse transforms. Exactly as if you had
> compiled "dummy_module" as:
> 
> erlc "+{parse_transform, dummy_transform1}" "+{parse_transform, dummy_transform2}" \
> +dummy_transform_option +other_dummy_transform_option dummy_module.erl
> 
> If someone were to implement support for per-transform options,
> it may be worth considering to add an (optional) third element to
> the "parse_transform" compile option (i.e. {parse_transform, Module, Opts}).
> 
> Regards,
> Enrique
> 
> 
> 2014-05-01 14:51 GMT+02:00 Fred Hebert <[email protected]>:
> What happens if I have a module defined as:
> 
>     -module(dummy_module).
> 
>     -compile({parse_transform, dummy_transform1}).
>     -compile({parse_transform, dummy_transform2}).
>     -compile(dummy_transform_option).
>     -compile(other_dummy_transform_option).
> 
> How does that end up working?
> 
> Regards,
> Fred.
> 
> On 05/01, Enrique Fernández Casado wrote:
> > Put compile options from code (i.e. -compile(myoption1)) into the options
> > variable used as second argument in parse_transform/2. This makes it
> > possible to access all compile options (i.e. the ones specified in the
> > command-line and the ones specified in code) in a consistent way.
> >
> > Here is a simple example:
> >
> > (dummy_module.erl)
> >
> > -module(dummy_module).
> >
> > -compile({parse_transform, dummy_transform}).
> > -compile(dummy_transform_option1).
> >
> >
> >
> > (dummy_transform.erl)
> >
> > -module(dummy_transform).
> >
> > -export([parse_transform/2]).
> >
> > parse_transform(Forms, Opts) ->
> >     true = lists:member(dummy_transform_option1, Opts),
> >     Forms.
> >
> >
> > Links:
> >
> > git fetch git://github.com/efcasado/otp.git compile-options
> >
> > https://github.com/efcasado/otp/compare/erlang:maint...compile-options
> > https://github.com/efcasado/otp/compare/erlang:maint...compile-options.patch
> >
> > https://github.com/erlang/otp/pull/350
> 
> > _______________________________________________
> > erlang-patches mailing list
> > [email protected]
> > http://erlang.org/mailman/listinfo/erlang-patches
> 
> 
> _______________________________________________
> erlang-patches mailing list
> [email protected]
> http://erlang.org/mailman/listinfo/erlang-patches

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com

_______________________________________________
erlang-patches mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-patches