Re: New Erlang-related macro

[Romain Lenglet]

Paul Eggert wrote:
> Romain Lenglet <address@hidden> writes:
> > In Erlang application "release files", the ERTS version
> > number must be given explicitly. In the general case,
> > applications really don't depend on a particular version,
> > but a precise version number is still required in every
> > release file.
>
> Why?  I don't know Erlang so you'll have to help me out here.

The doc about the Erlang/OTP release files is here:
http://www.erlang.org/doc/doc-5.5.1/lib/sasl-2.1.3/doc/html/rel.html
But I have made a summary below. ;-)

> Presumably there's a reason Erlang wants to know the ERTS
> version number.  Is that to handle version mismatches between
> the API that the source code expects, and the API of the
> interpreter?
> Whatever the reason, it needs to be documented; as things
> stand it's not clear why this new feature is useful.

Release files are used to specify which versions of the ERTS and 
dependent libraries an application depends on. That information 
is used to create a self-contained tarball that contains 
everything the application needs (the runtime + libraries), 
which can then be untared on the production system to work "out 
of the box".

Here is a typical .rel file:
{release, {"foo", "0.1"},
 {erts, "5.4"},
 [{kernel, "2.11"},
  {stdlib, "1.14"},
  {foo, "0.1"}]}.

Therefore, it is not used to check dependencies. And it cannot 
be, since there is no such checking feature in Erlang/OTP! 
Release resource files are rather used as a "source file" for 
creating self-contained tarball for applications.
There is nothing standard in Erlang/OTP to check dependencies / 
configurations. We are a few advocating for the autotools to do 
that.

The purpose of macros for substituting the ERTS version and 
library versions, is to "fill in" the .rel files automatically, 
e.g.:
{release, {"@PACKAGE_TARNAME@", "@PACKAGE_VERSION@"},
 {erts, "@ERLANG_ERTS_VERSION@"},
 [{kernel, "@ERLANG_LIB_VER_kernel@"},
  {stdlib, "@ERLANG_LIB_VER_stdlib@"},
  address@hidden@, "@PACKAGE_VERSION@"}]}.

A typical scenario is the following:
1) the user untars the application source tarball on the 
test/development system
2) he runs ./configure;make;make install
3) he test the application
4) he generates a release tarball from the .rel file, by calling 
Erlang function systools:make_rel/1
5) on the production system, he uncompresses the generated 
release tarball and starts the application


The purpose of the proposed macro substitution is to fill in 
automatically the .rel files with the versions of libraries and 
runtime that are actually available on the 
test/development/pre-production system.

To check (at step 2) that those available versions are suitable 
for this application, is out of the scope of those 
substitutions. It will be the purpose of other feature-testing 
macros (to test for the presence of modules and functions in 
available libraries, etc.).


Anyway, I agree that this should be explicitly documented 
somewhere.

-- 
Romain LENGLET