As for now, Automake provides no help to generate those files. This is Autoconf's job. What Autoconf can do is help you avoid the manual duplication of information between several files, and help you synchronize the content of the .app and .rel files with the state of your system and your Erlang/OTP installation. The trick is to let Autoconf generate parts of the .app and .rel files for you.

To let Autoconf substitute parts of those files, first add their names into the AC_CONFIG_FILES macro call, in your configure.ac file:


AC_CONFIG_FILES([... sample.app sample.rel])


Then, name your files with extensions .app.in and .rel.in, e.g. sample.app.in and sample.rel.in, as the configure script will generate sample.app from sample.app.in and sample.rel from sample.rel.in. Your .app.in and .rel.in files should contain variables to substitute enclosed with @...@.

For instance, a sample.app.in file could be:


{application, @PACKAGE@,
[{description, "Sample Erlang server"},
{vsn, "@VERSION@"},
{modules, [sample_app, sample_sup, sample_server]},
{registered, [sample_sup, sample_server]},
{applications, [kernel, stdlib]},
{mod, {sample_app, []}}
]}.


The @PACKAGE@ and @VERSION@ parts are substituted with the information supplied in the AC_INIT macro call in configure.ac.

Likewise, a sample.rel.in file could be:


{release, {"@PACKAGE@", "@VERSION@"}, {erts, "5.6.1"},
[{kernel, "@ERLANG_LIB_VER_kernel@"},
{stdlib, "@ERLANG_LIB_VER_stdlib@"},
{@PACKAGE@, "@VERSION@"}]}.


The variables ERLANG_LIB_VER_kernel and ERLANG_LIB_VER_stdlib contain the version numbers of the installed libraries named kernel and stdlib. To define such variables automatically with the versions of the libraries actually installed in your system, you just have to call the standard AC_ERLANG_CHECK_LIB Autoconf macro in your configure.ac file, e.g.:


AC_ERLANG_CHECK_LIB([kernel])
AC_ERLANG_CHECK_LIB([stdlib])


Note also that the ERTS version is not yet automatically determined by the standard Autoconf macros. However, Ruslan also proposed a new macro, AC_ERLANG_SUBST_ERTS_VER, to do that:


# AC_ERLANG_SUBST_ERTS_VER
# -------------------------------------------------------------------
AC_DEFUN([AC_ERLANG_SUBST_ERTS_VER],
[AC_REQUIRE([AC_ERLANG_NEED_ERLC])[]dnl
AC_REQUIRE([AC_ERLANG_NEED_ERL])[]dnl
AC_CACHE_CHECK([for Erlang/OTP ERTS version],
[erlang_cv_erts_ver],
[AC_LANG_PUSH(Erlang)[]dnl
AC_RUN_IFELSE(
[AC_LANG_PROGRAM([], [dnl
Version = erlang:system_info(version),
file:write_file("conftest.out", Version),
halt(0)])],
[erlang_cv_erts_ver=`cat conftest.out`],
[AC_MSG_FAILURE([test Erlang program execution failed])])
AC_LANG_POP(Erlang)[]dnl
])
AC_SUBST([ERLANG_ERTS_VER], [$erlang_cv_erts_ver])
])# AC_ERLANG_SUBST_ERTS_VER


You only have to put the code of that macro for instance in a acinclude.m4 file, placed in the same directory as the configure.ac file, and to call it in configure.ac:


AC_ERLANG_SUBST_ERTS_VER


That way, the ERLANG_ERTS_VER variable gets automatically defined with the detected installed ERTS version, and can be substituted in your .rel.in file, e.g. in sample.rel.in:

{release, {"@PACKAGE@", "@VERSION@"}, {erts, "@ERLANG_ERTS_VER@"},
[{kernel, "@ERLANG_LIB_VER_kernel@"},
{stdlib, "@ERLANG_LIB_VER_stdlib@"},
{@PACKAGE@, "@VERSION@"}]}.


Note to myself: I should really really take a little time to submit the definition of Ruslan's AC_ERLANG_SUBST_ERTS_VER macro to the GNU Autotools team for inclusion into the standard Autoconf...

Dryverl supports <dev-c-local-variable/> elements to declare local variables in the generated C code. The first bug was that Dryverl allows such an element to be empty, which would mean that the generated C local variable declaration has no specific initial value. However, in that case, Dryverl generated invalid declarations, such as:

int some_var = ();

Dryverl 0.1.3 now correctly generates no initializer in such cases:

int some_var;

The second bug was in the generated code that encodes output data, i.e. data that is returned from the C side to the Erlang side of the driver. As several methods are available in the Erlang port driver API to communicate between C and Erlang, Dryverl-generated drivers try to automatically use the most efficient one. The most efficient of all is the port call method. In the case the C code is invoked by a port call from the Erlang side, the emulator allocates itself a buffer that must be used for returning the output encoded data. The code generated by Dryverl automatically uses that buffer whenever possible, to avoid unnecessary memory allocation. However, if the encoded data exceeds that buffer, the generated code automatically switches to another method, which is to encode the output data as a separately allocated Erlang binary term, and reference that term from the output data encoded in the port call buffer.

The bug was that when the port call output buffer is exceeded, the data already encoded into it was not copied into the newly allocated Erlang binary's buffer, i.e. the start of that binary was left as garbage. The code generated by Dryverl 0.1.3 now correctly handles that case by copying the port call output buffer data into the Erlang binary buffer, before using that Erlang binary to further encode output data.

That second bug is of a kind that is very hard to trigger, because of the very large number of possible combinations of methods that can be used to communicate between Erlang and C, and because the code generated by Dryverl, and the strategy chosen by that code, depend on several conditions: are binaries sent in input? in output? are asynchronous threads used? is the encoded output data too large to fit the port call output buffer?, etc.

Thanks a lot to Hunter Morris for spotting those two bugs and for submitting a patch.