[erlang-patches] Put compile options from code into parse_transform/2 options variable

[Enrique Fernández Casado]

Thanks for sharing, Ulf.

The solution you propose in parse_trans:option_value/3 is exactly what I
ended up implementing in my project. However, IMHO, it does not feel right
that one has to scan the forms of a module in order to get hold of compile
options specified in the module being parse transformed. Specially when the
parse_transform/2 function has an "options" variable that already contains
a list of **some** compile options (including any {parse_transform, Module}
option that may have been defined in that module. This sounds a little bit
counterintuitive to me.

IMHO, the second argument of the parse_transform/2 function should contain
a list of all compile options targeting the module being parse transformed,
unless there is a good reason for not doing so.



2014-05-01 21:40 GMT+02:00 Ulf Wiger <ulf@REDACTED>:

>
> 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 <efcasado@REDACTED>
> 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 <mononcqc@REDACTED>:
>
>> 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
>> > erlang-patches@REDACTED
>> > http://erlang.org/mailman/listinfo/erlang-patches
>>
>>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
>
>
> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
> http://feuerlabs.com
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140501/d9c04c81/attachment.htm>