<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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">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">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">https://github.com/Feuerlabs/exometer/blob/master/src/exometer_igor.erl</a></div><div><br></div><div>BR,</div><div>Ulf W</div><br><div><div>On 01 May 2014, at 19:47, Enrique Fernández Casado <<a href="mailto:efcasado@gmail.com">efcasado@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><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 class="h5"><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">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">erlang-patches@erlang.org</a><br>http://erlang.org/mailman/listinfo/erlang-patches<br></blockquote></div><br><div apple-content-edited="true">
<span class="Apple-style-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">http://feuerlabs.com</a></div></div><div><br></div></span><br class="Apple-interchange-newline">

</div>
<br></body></html>