Re: [guppi-list] New Guppi Snapshot

[Rob Browning <rlb cs utexas edu>]

Jon Trowbridge <trow@emccta.com> writes:

> Back when I first did my binding stuff, I didn't know g-wrap
> existed.  (In fact, I didn't really know that g-wrap existed until
> this thread.)  I'll download the source and look at it.

Robert and I are working on g-wrap these days, and if you decide
you're interested, we'd be more than happy to augment it to accomodate
your needs.

> I'm all for common solutions to these sorts of things.  (I was
> originally going to steal the code generator that guile-{gtk,gnome}
> uses, but I had problems getting it to work with anything but its own
> configuration...)

In addition to the g-wrap source tree, you can look in gnucash's
source at src/guile/gnc.gwp to see all the gnucash spec file.  That
should give you some idea of how g-wrap works from the end-user
perspective.

In the long run, I'd like to try and make sure that the g-wrap spec
for an API is a very accurate and target-language independent
specification of the library's semantics (including memory semantics -
who owns pointers, etc.), that way, even if g-wrap goes the way of the
do-do, and if there's an accumulation of g-wrap spec files for various
libs, someone can just write a simple scheme converter that'll read
those files and spit out CORBA specs, or whatever else is big then -
another advantage to an easily parsable syntax.

One thing on the medium term burner is to rework g-wrap to allow you
to generate libXXX.so files that interact seamlessly with guile's
module system and dynamic (run-time dlopen) loading.  Guile knows how
to do that, and it shouldn't be too hard to have g-wrap handle the
infrastructure.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930