[Caml-list] re: swig like library...

[Caml-list] re: swig like library...

[Micha]

ok, now there are forklift, idl and swig. swig seems to be the only lib which 
can create an interface to a c++ lib. The IDL docu mentions c++ but only with 
com; or did I misunderstand something?
So to interface to a c++ lib I first have to create the relevant c-lib and 
then with idl or forklift the rest, or use swig from the beginning, or by 
hand, which seems much to type :-)

Has someone experiences interfacing to a c++ - lib? 

 Michael

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: swig like library...

[Jeff Henrikson]

> Any interest in an Ocaml based SWIG like tool?

When I put on hiatus my Forklift development, I was thinking a lot about the following problem, which I made up to focus my path.

==> Make precise the relationship between the immutable C header files and the assignments of stubs, HLL types, and HLL modules.  In order to separate pattern matching from stub generation, output an abstract representation.  Suppose we choose IDL as that abstract representation.  Then give a pattern matching system that filters C header ASTs according to pattern rules and generates both a IDL file to make them CORBA callable, and C function wrappers to make them conform to the CORBA->C language mapping.

Here is the CORBA->C language mapping:

http://www.omg.org/technology/documents/formal/corba_language_mapping_specs.htm

Hey, as a bonus, if we solve this problem we build a machine for making arbitrary C code easily CORBA callable, a useful ability in its own right.  I have seen requests on CORBA lists for solutions to this problem.

Last time I tried to work on this, I got very frustrated just trying to find a IDL that would compile on Darwin.  Geesh.  I gues one of the things that happens when you build a layer that has an ability to translate every last type is you make a monster in its configure script.


Jeff Henrikson



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: swig like library...

[Jeff Henrikson]

> I think the whole system should be reorganised so the core SWIG
> builds independently of ANY language module (except perhaps
> an XML or debugging output module), and each language module
> should be an independent 'add on' in a separate CVS module.

> > SWIG isn't strictly *for C*, it's for standard C++ and is not designed
> > to accept core C headers or GNU extensions (this is part of why it works
> > with incomplete type information, and missing includes).  It's assumed

GCC can output its own XML tree.

http://www.gccxml.org/HTML/Index.html

(I wish this would get incorporated into the main branch.)

When I set up Forklift the way I have, I never envisioned C++ to be a grammar to base a wrapper generator on.  C++ does not expand the ABI of C.  Just the syntax.  I pictured writing a preprocessing front end to get C++ into a C library.  In the old days of C++, many libraries included these C headers as a matter of course.  (Eg: OpenInventor from SGI)  That transformation, unlike wrapper generation, _is_ well defined from only the information given in the header files.

This approach would place on equal grounds Oop styled C libs (eg: GTK) from Oop syntaxed C++ libs (eg: OpenInventor).


Jeff Henrikson


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners