* [Caml-list] Confusion about camlidl capabilities? other tools? @ 2001-08-13 19:26 Jeff Henrikson 2001-08-14 7:51 ` Xavier Leroy 0 siblings, 1 reply; 3+ messages in thread From: Jeff Henrikson @ 2001-08-13 19:26 UTC (permalink / raw) To: caml-list 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Caml-list] Confusion about camlidl capabilities? other tools? 2001-08-13 19:26 [Caml-list] Confusion about camlidl capabilities? other tools? Jeff Henrikson @ 2001-08-14 7:51 ` Xavier Leroy 0 siblings, 0 replies; 3+ messages in thread From: Xavier Leroy @ 2001-08-14 7:51 UTC (permalink / raw) To: Jeff Henrikson; +Cc: caml-list > 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <20010813225308.B23936@dpt-info.u-strasbg.fr>]
* RE: [Caml-list] Confusion about camlidl capabilities? other tools? [not found] <20010813225308.B23936@dpt-info.u-strasbg.fr> @ 2001-08-14 0:26 ` Jeff Henrikson 0 siblings, 0 replies; 3+ messages in thread From: Jeff Henrikson @ 2001-08-14 0:26 UTC (permalink / raw) To: Sven; +Cc: caml-list > 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-08-14 7:52 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-08-13 19:26 [Caml-list] Confusion about camlidl capabilities? other tools? Jeff Henrikson 2001-08-14 7:51 ` Xavier Leroy [not found] <20010813225308.B23936@dpt-info.u-strasbg.fr> 2001-08-14 0:26 ` Jeff Henrikson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox