This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
I've put a new version of g-wrap at its home page: http://www.cs.cmu.edu/~chrislee/g-wrap/ Release 0.3.7 is built using GNU auto-configuration tools, and includes new code for automatically exporting functions by scanning source files. This new automatic-export code was originally in a separate package called "g-translate". Some preliminary work on automatically generating html descriptions of the generated scheme primitives is also included, and an example is on the home-page. A user manual, in texinfo format, is included. Online versions in postscript and html are available from the g-wrap home page. I am not sure how many people are using this package, but I think it is in a pretty usable state now, and I use it for maintaining a large project which exports hundreds of functions and several types to Guile. -Chris ps. The project I use with G-Wrap is a matrix library, which I hope to release in the near future, once I resolve some dynamic-loading issues and switch it to autoconf-based configuration. pps. The following is some documentation on the automatic function export capability of G-Wrap: Scanning source code for functions to export -------------------------------------------- - Function: gwrap-c-scan-source-file FILENAME This command looks through FILENAME for ANSI function declarations that are preceded by a special comment, and does some simplistic parsing to find out enough about each function to write a wrapper function for it. To export a function, simply add the following comment before an ANSI function declaration (note, the `/*[' must be the first characters on the line, no indenting): /*[EXPORT FLAGS] DESCRIPTION */ where DESCRIPTION is a short description of what the function does, and FLAGS (usually left empty) can indicate that g-wrap should override its default assumptions about return type, parameter types, or function name. If FLAGS contains: * `(name NEW-NAME)' the function is exported as NEW-NAME. * `(types ((N NEW-TYPE) ...))' the type of the N-th parameter (the first parameter is 0) is assumed to be NEW-TYPE. * `(ret-type NEW-TYPE)' the return type of the function is assumed to be NEW-TYPE. Up to three characters of each line of DESCRIPTION are ignored if they are space or '*' characters. For example, if this function definition is in `lmatrix.c', /*[EXPORT (ret-type RETVEC0)] * out := A.x */ VEC *mv_mlt(VEC *v_out, MAT *A, VEC *x) { .... } then these lines in the library description file (set! type-translations (append '((VEC* VEC) (MAT* MAT)) type-translations)) (gwrap-c-scan-source-file "lmatrix.c") will be equivalent to (new-function 'mv-mlt 'RETVEC0 "mv_mlt" '((VEC v-out) (MAT A) (VEC x)) "out := A.x")