Announcing Dryverl: an Erlang-to-C binding compiler

[Romain Lenglet]

Richard A. O'Keefe wrote:
> I downloaded dryverl-0.1 from the ObjectWeb site.
[...]
> Looking at examples/Makefile, it is quite hard to see what is
> going on. I can't quite see where $(srcdir) is set, but
> wherever it is set, it is wrong for this example.  Patching
> the corresponding line of the Makefile to use
> ../hello/configure instead of $(srcdir)/hello/configure gets a
> long way further.

srcdir is set by the configure script. The problem is that if                           
building in-tree srcdir is set to ".", which is a relative path, 
and my Makefile.am did not deal well with a relative srcdir.
I always tested out-of-tree building, and using absolute paths to 
configure, so I did not encounter that case.

That bug is fixed in version 0.1.1:
http://forge.objectweb.org/forum/forum.php?forum_id=1020

Thanks for the report.

> By the way, six languages in one tool is a little
> overwhelming. It would be much simpler for bears of very
> little brain if interfacing between Erlang and C only required
> them to know Erlang, C, and maybe *one* more notation.

As David Hopwood remarked from my previous fragment of spec, the 
Erlang+XML and C+XML dialects are similar to simple 
Erlang+macros and C+macros languages. For instance, in the 
Erlang+XML dialects, only three elements have been defined. See 
complex "EncodeInputErlangCode" and "DecodeOutputErlangCode" 
element types in the XMLSchema.

However, this does not mean that this can be implemented using 
only pre-processors, because having all fragments specifying a 
binding in the same specification file is essential: there are 
semantic constraints between the fragments of a binding, in the 
different dialects. For instance, if the decode-input C fragment 
contains XML elements for decoding binaries passed by reference, 
there must be a corresponding encoding Erlang fragment in the 
encode-input.

-- 
Romain LENGLET