> 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