On Mon, 16 Feb 2009 21:18:48 +0000
Jon Harrop <jon at ffconsultancy.com> wrote:>
> On Monday 16 February 2009 20:04:38 Paul Melis wrote:
> Yes. I similarly found that tail calls, sret and parts of first-class
structs
> are not usable from OCaml and much of the functionality was not implemented
> in the C API in LLVM 2.4.
>
>> SWIG (www.swig.org) recently added a C output mode, that is capable of
>> generating a C API for a C++ one.
>> It was a Summer of Code project, so I'm not sure how mature it is.
The
>> docs are here:
>>
http://swig.svn.sourceforge.net/viewvc/swig/branches/gsoc2008-maciekd/Doc/M
>>anual/C.html
>
> The generation of this FFI code should certainly be automated. However, if
the
> necessary tools are not yet stable perhaps it would be wise to consider
> looser bindings such as XML-RPC? I assume there are tools that can examine
a
> C++ API from headers in order to create an XML-RPC server automatically?
>
> An XML-RPC API would be trivial to use and extend from languages like OCaml
> and Python and the interface code should not require any maintenance at
all.
>
XML-RPC assumes you want an external server, or it can be used from
the same process?
If SWIG is not mature enough, and/or doesn't provide the needed level
of flexibility, we have other options:
* write a llc backend that generates C-bindings for C++ compiled code
(general solution, could replace SWIG).
* write a perl script that parses nm output from LLVM libraries and
creates the binding code.
Maybe I'll try one of those approaches when I have time... Do we have
coding conventions in LLVM to distinguish private methods from public
methods in classes, in order to easily identify which methods should
be exported?
Corrado