carlosedp/rebar3_diameter_compiler

Compile Diameter .dia files on Erlang Rebar3 projects

rebar3_diameter_compiler

Compile diameter .dia files in rebar3 projects

Build

./rebar3 compile

Use

Add the plugin to your rebar config from Github:

{plugins, [
    { rebar3_diameter_compiler, {git, "https://github.com/carlosedp/rebar3_diameter_compiler.git", {branch, "master"}}}
]}.

{provider_hooks, [
    {pre, [
        {compile, {diameter, compile}},
        {clean, {diameter, clean}}
    ]}
]}.

Or fetch the plugin using Hex.pm:

{plugins, [
    rebar3_diameter_compiler
]}.

{provider_hooks, [
    {pre, [
        {compile, {diameter, compile}},
        {clean, {diameter, clean}}
    ]}
]}.

The plugin will be ran on compile and clean commands or call your plugin directly in an existing application:

$ rebar3 diameter compile
===> Fetching rebar3_diameter_compiler
===> Compiling rebar3_diameter_compiler
===> Compiling diameter...

$ rebar3 diameter clean
===> Cleaning diameter compiled files...

The option specified below allows to compile only specific diameter dictionaries

{dia_only_files, [
    your_dictionary
    ]}.

Test

One test compiles a .dia file for validation, another compares the generated erl/hrl files with the expected files in test/expected directory.

rebar3 eunit

If the format changes in the future(for example due a compiler change), the expected files can be re-generated with GOLDEN_RUN=1 rebar3 unit. This will overwrite the existing expected files.

Publishing new versions

This is mostly a reminder on how to bump and publish a new version.

# Login to Hex
rebar3 hex user auth
# Cut new version with hex
rebar3 hex cut

rebar3_diameter_compiler's Issues

Problem with @name

Hi !
I think there is a problem with file name.
I have some .dia files which has @name parameter inside. It defines the name of the generated dictionary module. Everything is fine when the @name value is the same as the file name, otherwise there is a problem during compilation.

Case:
File rfc4005_nas.dia :

@name diameter_gen_rfc4005_nas
@inherits diameter_gen_base_rfc3588

File rfc4006_cc.dia:

@name diameter_gen_rfc4006_cc
@inherits diameter_gen_base_rfc3588
@inherits diameter_gen_rfc4005_nas

It work only if this files names have diameter_gen_ prefix. I think it worked with rebar v2.

Unit tests

I'd love to have a couple of test cases to make sure the compiler is working.

Could you help out on this @RoadRunnr and @ebengt? I'm a little rusty on Erlang :)

compilation fails; .beam files not generated in time?

I've been playing with diameter dictionairies with lots of internal dependencies, and I'm having some troubles with the rebar3_diameter_compiler. It actually resolves the dependencies and compiles a couple of .dia files to .erl/.hrl, but then when trying to compiler more of them, apparently it tries to compile .dia files without having the .beam files of the dependencies built.

In case you're interested, I've pushed the code to a temporary repository (even with typo in the name) at https://github.com/laf0rge/osmo_diamete2gsup

I'm not sure why it's not generating the .beam file before doing the next .dia -> erl/hrl translation.

If I compile the code manually, it works.

Undefined rebar_app_discover:find_app/2

rebar3_diameter_compiler/src/compile_diameter.erl:32 calls rebar_app_discover:find_app/2
That function is not available in rebar 3.16.1 on Erlang/OTP 24 Erts 12.0

At a guess plugins should use
rebar_app_info:discover/2
but it is difficult to tell from the source which is the interface module.

Don't use 'project_apps'

Use of project_apps is actually a special case for rebar3 providers or providers that are to only be run at the top level (like the todo list plugin). But since a plugin like this needs to also work when being used by a dependency it should work like the erlydtl plugin by using rebar_state:dir/1 to find what app/dir it is currently working on: https://github.com/tsloughter/rebar3_erlydtl_plugin/blob/master/src/rebar3_erlydtl_plugin.erl#L125