76 lines
3.2 KiB
Plaintext
76 lines
3.2 KiB
Plaintext
From: aa8vb at vislab.epa.gov (Randall Hopper)
|
|
Date: Tue, 6 Apr 1999 15:19:50 GMT
|
|
Subject: SWIG, Modulator, BGEN, etc. - which? (Re: swig or not to swig ?)
|
|
In-Reply-To: <002b01be803c$635a54d0$6fc6a8c0@rochester.rr.com>; from Darrell on Tue, Apr 06, 1999 at 10:47:26AM -0400
|
|
References: <4p6O2.1348$8m5.2126@newsr1.twcny.rr.com> <kZ6O2.1351$8m5.2222@newsr1.twcny.rr.com> <gm7O2.1356$8m5.2172@newsr1.twcny.rr.com> <3709f149.2262513@news.oh.verio.com> <19990406103412.A869943@vislab.epa.gov> <002b01be803c$635a54d0$6fc6a8c0@rochester.rr.com>
|
|
Message-ID: <19990406111950.A870049@vislab.epa.gov>
|
|
Content-Length: 2603
|
|
X-UID: 1570
|
|
|
|
Darrell:
|
|
|> I'm also interested in what wrapping options folks like best.
|
|
|> Roll-your-own, SWIG, Modulator, BGEN? (Do others not listed exist for
|
|
|UNIX?)
|
|
|
|
|
|These are the only options I've found. I just started playing with Modulator
|
|
|and it will very much simplify a Roll-your-own approach. BGEN is my next
|
|
|option to try.
|
|
|
|
|
|I believe that BGEN is the only one that tries to parse .h files, which
|
|
|sounds like what you want.
|
|
|I'll let you know how it goes.
|
|
|
|
Thanks. I'd appreciate that.
|
|
|
|
BTW, SWIG parses header files as well. Of the 3, it is the only one I've
|
|
used, and I haven't spent a lot of time with it yet.
|
|
|
|
It does a good bit, and it supports generating a Python "shadow class"
|
|
for structures it encounters which can be convenient. Also, once you get
|
|
the .i file cooked, ideally you can generate wrappers for Python, Perl,
|
|
Tcl, and others coming down the pike no more modificiation.
|
|
|
|
Of the 2 small C libraries I've wrapped for Python thus far, I had to
|
|
augment it's default behavior in a couple ways by customizing the
|
|
SWIG configuration (.i) file for the libraries:
|
|
|
|
1) For struct parameters, explicitly define wrapper "constructor" and
|
|
"destructor" methods for the struct. These are exposed as new
|
|
functions that are named new_<struct> and delete_<struct>.
|
|
|
|
2) Define access routines in the wrapper for struct members.
|
|
(These communicate errors to exception wrappers using an ad-hoc
|
|
wrapper-module-scope variable.)
|
|
|
|
3) Define a number of exception wrappers to turn C function errors
|
|
and even wrapper function errors into script language exceptions.
|
|
|
|
(Unfortunately, new functions defined in the wrapper can't throw their
|
|
own exceptions. They have to communicate these out-of-line to
|
|
exception wrappers which then trigger the scripting language
|
|
exceptions.)
|
|
|
|
4) Define which function parameter names are output parameters.
|
|
|
|
5) Double wrap functions which return values in arguments and
|
|
success/failure in the return value, so I can get a tuple in Python.
|
|
|
|
E.g.: %apply float *OUTPUT { float *x, float *y };
|
|
int GetPoint( struct S *s, int *x, int *y )
|
|
|
|
By default this returns a 3-tuple. We don't care about the function
|
|
return value in Python (it's translated into an exception by the
|
|
exception wrapper) so we must double-wrap to toss it.
|
|
|
|
It works. However, there is enough non-trivial wrapper code (123 lines for
|
|
one of these libraries; a maintenance issue) that I thought it'd be
|
|
worthwhile to survey what other options are out there.
|
|
|
|
Randall
|
|
|
|
|
|
|
|
|
|
|
|
|