RE: [Caml-list] Confusion about camlidl capabilities? other tools?

RE: [Caml-list] Confusion about camlidl capabilities? other tools?

[Jeff Henrikson]

> I started working some time ago on c2caml, which, altough maybe not
> what you need, was intented to generate ocaml stubs from C header
> code, particularly for parsing the gtk+ headers and generating
> appropriate bndings. It is really jus ta C parser for now, but if
> you want, you can look at it, it is availabel in the CDK, i think.

No, wrong way.  I want to publish a control implemented in caml to the outside world.  Parsing C is not involved.  Printing a bunch
of C is.

Note that this is easier than the reverse: C header files are underspecified and need a markup language (MIDL, SWIG) to make stub
generation well defined.  mli files on the other hand have everything you need to interface to C or something else.


Jeff Henrikson

> -----Original Message-----
> From: Sven [mailto:luther@dpt-info.u-strasbg.fr]
> Sent: Monday, August 13, 2001 4:53 PM
> To: Jeff Henrikson
> Subject: Re: [Caml-list] Confusion about camlidl capabilities? other
> tools?
>
>
> On Mon, Aug 13, 2001 at 03:26:46PM -0400, Jeff Henrikson wrote:
> > Hi,
> >
> > Reading the documentation of camlidl, it says that caml objects can be exported for use in C/C++ programs.  Looking at
> the source
> > code, the support for this looks minimal.  I see the camlidldll script, which is just a shell script that links a caml
> program with
> > some executable code.  If this is some sort of automatic dispatch interface generator, this is not what I want.  I want real C
> > header files from just plain unannotated mli.  Preferably a system with ability to map variants into C struct/unions
> coupled with
> > utility functions.  I'm not sure which other advanced ocaml datatypes I need beyond variants and the basic ints,
> strings, arrays
> > and etc.
> >
> > Has anybody done something like this?  I ripped out the ocaml parser and started playing with it to build a tool, but
> I don't want
> > to be reinventing the wheel.  While I'm at it, I will probably try to export stubs at least these styles: COM,
> GTK-style C objects,
> > and SWIG-ready header files for inclusion in Python or TCL or whatever some unenlightened person would want to use.
>
> I started working some time ago on c2caml, which, altough maybe not what you
> need, was intented to generate ocaml stubs from C header code, particularly
> for parsing the gtk+ headers and generating appropriate bndings. It is really
> jus ta C parser for now, but if you want, you can look at it, it is availabel
> in the CDK, i think.
>
> Friendly,
>
> Sven Luther
>

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Confusion about camlidl capabilities? other tools?

[Xavier Leroy]

> Reading the documentation of camlidl, it says that caml objects can
> be exported for use in C/C++ programs.  Looking at the source code,
> the support for this looks minimal.  I see the camlidldll script,
> which is just a shell script that links a caml program with some
> executable code.

This is just a convenience script.  The gist of CamlIDL is that it
generates stub code + a Caml interface from a C-like interface
expressed in IDL (basically, it's a C include file with annotations).
This provides Caml/C (and a little C++) interoperability in situations
where the C interface is fixed.  But that's not what you want:

> I want real C header files from just plain unannotated mli.
> Preferably a system with ability to map variants into C
> struct/unions coupled with utility functions.  I'm not sure which
> other advanced ocaml datatypes I need beyond variants and the basic
> ints, strings, arrays and etc.

What you need is Camouflage by Robbert van Renesse:
        ftp://ftp.cs.cornell.edu/pub/rvr/camou-1.1.tar.gz
>From the announcement:

  Camouflage 1.1 is a tool that supports interfacing between C and OCaml.
  Camouflage reads a .mli file and creates the necessary C interfaces to
  the given module.  This way the fact that a library is written in OCaml
  can be ``camouflaged.''  Camouflage also supports creating OCaml interfaces
  to C functions, and generates functions that convert between OCaml and C
  data structures.

  For example, let say "x.mli" contains the declaration "val add: int ->
  int -> int".  Then the command "camou x.mli" creates a file "x.c" that
  contains the C function "int X_add(int, int)" which does all the stuff
  necessary to invoke the ML function.  Vice versa, the declaration
  "external add: int -> int -> int" creates an ML function to invoke
  a corresponding C function.

> While I'm at it, I will probably try to export stubs at least these
> styles: COM, GTK-style C objects, and SWIG-ready header files for
> inclusion in Python or TCL or whatever some unenlightened person
> would want to use.

Sounds good.  I don't think Camouflage does any of this, and it hasn't
been updated in a while, but I think it could be a good starting
point.

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

[Caml-list] Confusion about camlidl capabilities? other tools?

[Jeff Henrikson]

Hi,

Reading the documentation of camlidl, it says that caml objects can be exported for use in C/C++ programs.  Looking at the source
code, the support for this looks minimal.  I see the camlidldll script, which is just a shell script that links a caml program with
some executable code.  If this is some sort of automatic dispatch interface generator, this is not what I want.  I want real C
header files from just plain unannotated mli.  Preferably a system with ability to map variants into C struct/unions coupled with
utility functions.  I'm not sure which other advanced ocaml datatypes I need beyond variants and the basic ints, strings, arrays
and etc.

Has anybody done something like this?  I ripped out the ocaml parser and started playing with it to build a tool, but I don't want
to be reinventing the wheel.  While I'm at it, I will probably try to export stubs at least these styles: COM, GTK-style C objects,
and SWIG-ready header files for inclusion in Python or TCL or whatever some unenlightened person would want to use.

I can't say how much I aprecate the simplicity of the ocamlc tools.  I would never have standalone compiled the parser for gcc into
any interesting form in 30 minutes.  Damn all the #ifdefs and sizeof(int) and other cruft of C culture.  And the caml language is
nice enough to where I'll actually be able to get a decent amount of the necessary behavior quickly.  A C abstract syntax tree
would be much less pleasant to deal with.


Thanks,


Jeff Henrikson

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr