#6 dependencies not visible to erlc

1.0.0-beta
closed-accepted
nobody
None
5
2011-01-21
2011-01-19
No

If you have an erlang-otp artifact referenced as a dependency with in a POM, the artifact is unpacked (as expected) in ./target/lib. However, this code path is not visible to erlc during the erlang:compile phase. Where this is particularly problematic is in regard to -include/-include_lib declarations that depend on emitting the erlc command with the proper -I directive (in this case, -Itarget/lib). The proposed fix is to make -Itarget/lib a default.

Furthermore, the documentation for erlang:compile indicates that <erlcOptions> may be used to add additional parameters to the compiler. However, if you attempt to add something like <erlcOptions>-Itarget/lib</erlcOptions>, the plugin will bail out because it doesn't like the token. Parsing the maven-erlang-plugin source code, it seems like the token is supposed to be <compilerOptions>. However, setting this option fixes the parse error, but does not take effect on the erlang:compile phase as evident from the following output from a run of "mvn package -X"

[DEBUG] Executing [erlc, -I, /home/ghaskins/sandbox/git/gwtclient/example-server/target/include, -I, /home/ghaskins/sandbox/git/gwtclient/example-server/src/main/erlang, -o, /home/ghaskins/sandbox/git/gwtclient/example-server/target/ebin, +report_errors, +report_warnings, /home/ghaskins/sandbox/git/gwtclient/example-server/src/main/erlang/example_app.erl, /home/ghaskins/sandbox/git/gwtclient/example-server/src/main/erlang/example_server.erl, /home/ghaskins/sandbox/git/gwtclient/example-server/src/main/erlang/example_sup.erl]

Discussion

  • Tobias Schlager

    Tobias Schlager - 2011-01-20

    Thanks for your detailed report.

    You're right the include_lib directive is an important feature that currently does not work in version 1.0.0-beta. Version 2.0.0-SNAPSHOT (as found on the trunk) has already solved this probelm.

    Though, the problem is not the include path but that erlc needs the code paths of the dependency applications when compiling (include_lib uses code:lib_dir internally). This is really ugly since you must pass -pa ... to the erlc command. The new version does use a backend node which has the proper paths added.

    Please note that the site documentation which states the erlcOptions refers to version 1.0.0-beta, while the trunk source code has version 2.0.0-SNAPSHOT (the erlcOptions string array was replaced by the string parameter compilerOptions because version 2.0.0-SNAPSHOT does use compile:file/2 instead of erlc).

    To pass string array parameters you have to use something like this:
    <erlcOptions>
    <erlcOption>option1</erlcOption>
    <erlcOption>option2</erlcOption>
    ...
    </erlcOptions>

    The only quick workaround for your problem in 1.0.0-beta is to replace all -include_lib directives in your code using -include omitting the path.

    I would recommend to try the 2.0.0-SNAPSHOT version of the plugin, its pretty stable right now and we could really use some decent feedback. Updating to 2.0.0-SNAPSHOT will require some minor changes in the pom and project structure but there's lots of documentation if you check out the trunk and build it locally (mvn site).

     
  • Tobias Schlager

    Tobias Schlager - 2011-01-20
    • milestone: --> 1.0.0-beta
    • status: open --> open-accepted
     
  • Greg Haskins

    Greg Haskins - 2011-01-21

    Indeed, I was confused by the fact that trunk had moved on to 2.0.0-SNAPSHOT w.r.t. the erlcOptions/compilerOptions issue.

    I was also confused by the <erlcOptions><erlcOption> thing.

    Before you had commented, I had already moved on to using a 2.0.0-SNAPSHOT and have been having good luck there. Thanks for this awesome project. I think this bug can be closed.

     
  • Greg Haskins

    Greg Haskins - 2011-01-21
    • status: open-accepted --> closed-accepted
     

Log in to post a comment.