<div dir="ltr">Thanks for sharing, Ulf.<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-01 21:40 GMT+02:00 Ulf Wiger <span dir="ltr"><<a href="mailto:ulf@feuerlabs.com" target="_blank">ulf@feuerlabs.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>I have done a few things in this area:</div><div><br></div><div>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:</div>
<div><br></div><div><a href="https://github.com/uwiger/parse_trans/blob/master/src/parse_trans.erl#L397" target="_blank">https://github.com/uwiger/parse_trans/blob/master/src/parse_trans.erl#L397</a></div><div><br></div><div>
I haven’t exported parse_trans:option_value/3, but it’s fairly simple:</div><div><a href="https://github.com/uwiger/parse_trans/blob/master/src/parse_trans.erl#L457" target="_blank">https://github.com/uwiger/parse_trans/blob/master/src/parse_trans.erl#L457</a></div>
<div><br></div><div>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:</div><div><br></div><div><a href="https://github.com/Feuerlabs/exometer/blob/master/src/exometer_igor.erl" target="_blank">https://github.com/Feuerlabs/exometer/blob/master/src/exometer_igor.erl</a></div>
<div><br></div><div>BR,</div><div>Ulf W</div><div><div class="h5"><br><div><div>On 01 May 2014, at 19:47, Enrique Fernández Casado <<a href="mailto:efcasado@gmail.com" target="_blank">efcasado@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">AFAIK, there is no way to specify per-transform options. So <div>all four compile options will end up in the "options" variable<br></div><div>of the two specified parse transforms. Exactly as if you had</div>
<div>compiled "dummy_module" as:</div><div><br></div><div>erlc "+{parse_transform, dummy_transform1}" "+{parse_transform, dummy_transform2}" \</div><div>+dummy_transform_option +other_dummy_transform_option dummy_module.erl</div>
<div><br></div><div>If someone were to implement support for per-transform options,</div><div>it may be worth considering to add an (optional) third element to</div><div>the "parse_transform" compile option (i.e. {parse_transform, Module, Opts}).</div>
<div><br></div><div>Regards,</div><div>Enrique</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-01 14:51 GMT+02:00 Fred Hebert <span dir="ltr"><<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What happens if I have a module defined as:<br>
<br>
-module(dummy_module).<br>
<br>
-compile({parse_transform, dummy_transform1}).<br>
-compile({parse_transform, dummy_transform2}).<br>
-compile(dummy_transform_option).<br>
-compile(other_dummy_transform_option).<br>
<br>
How does that end up working?<br>
<br>
Regards,<br>
Fred.<br>
<div><div><br>
On 05/01, Enrique Fernández Casado wrote:<br>
> Put compile options from code (i.e. -compile(myoption1)) into the options<br>
> variable used as second argument in parse_transform/2. This makes it<br>
> possible to access all compile options (i.e. the ones specified in the<br>
> command-line and the ones specified in code) in a consistent way.<br>
><br>
> Here is a simple example:<br>
><br>
> (dummy_module.erl)<br>
><br>
> -module(dummy_module).<br>
><br>
> -compile({parse_transform, dummy_transform}).<br>
> -compile(dummy_transform_option1).<br>
><br>
><br>
><br>
> (dummy_transform.erl)<br>
><br>
> -module(dummy_transform).<br>
><br>
> -export([parse_transform/2]).<br>
><br>
> parse_transform(Forms, Opts) -><br>
> true = lists:member(dummy_transform_option1, Opts),<br>
> Forms.<br>
><br>
><br>
> Links:<br>
><br>
> git fetch git://<a href="http://github.com/efcasado/otp.git" target="_blank">github.com/efcasado/otp.git</a> compile-options<br>
><br>
> <a href="https://github.com/efcasado/otp/compare/erlang:maint...compile-options" target="_blank">https://github.com/efcasado/otp/compare/erlang:maint...compile-options</a><br>
> <a href="https://github.com/efcasado/otp/compare/erlang:maint...compile-options.patch" target="_blank">https://github.com/efcasado/otp/compare/erlang:maint...compile-options.patch</a><br>
><br>
> <a href="https://github.com/erlang/otp/pull/350" target="_blank">https://github.com/erlang/otp/pull/350</a><br>
<br>
</div></div>> _______________________________________________<br>
> erlang-patches mailing list<br>
> <a href="mailto:erlang-patches@erlang.org" target="_blank">erlang-patches@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-patches" target="_blank">http://erlang.org/mailman/listinfo/erlang-patches</a><br>
<br>
</blockquote></div><br></div>
_______________________________________________<br>erlang-patches mailing list<br><a href="mailto:erlang-patches@erlang.org" target="_blank">erlang-patches@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-patches" target="_blank">http://erlang.org/mailman/listinfo/erlang-patches</a><br>
</blockquote></div><br></div></div><div>
<span style="border-collapse:separate;border-spacing:0px"><div><div>Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.</div><div><a href="http://feuerlabs.com" target="_blank">http://feuerlabs.com</a></div></div>
<div><br></div></span><br>
</div>
<br></div></blockquote></div><br></div>