On man, 2002-09-09 at 18:43, Scott Smith wrote:
> I really would like to see this done, so I started on it last weekend.
>
Great news.
> Here is a general overview of what I was thinking, and following that,
> what I've got so far. Some of the overview is basic if you're into XS.
> I'm not, yet, really. It looks like everyone who has played with it
> is roughly on the same page, though I haven't tried inline C yet.
> I was shooting for XS.
>
There is really no difference between Inline::C and XS except for
automatic compilation.
> * Libraries and header files:
>
> The libraries used to compile C programs using Gtk2 are the ones
> we want to wrap with Perl modules. While certain binutils tools like nm
> can tell us the names of functions in the library directly, we need,
> I believe, the header files to get the exact prototype.
>
> On systems with pkg-config installed, getting the list of both
> libraries and header files for gtk2 is easy:
>
> pkg-config gtk+-2.0 --cflags --libs
>
> The libraries include gtk, gdk, pango, atk, glib, and a few
> others upon which gtk is dependent.
>
> * After wrapping the libraries:
>
> While basic wrappers for the libraries would be nice,
> all we'd be left with is perl code like:
>
> use libgtk;
> my $winptr = libgtk::gtk_window_new();
> libgtk::gtk_window_set_title($winptr,"My Title");
>
This would be silly.
XS will do all the wrapping for you.
You just give the XS compiler a couple of hints, and the methods will be
placed in the right packages.
The hints in this case would be:
MODULE = Gtk::Window PACKAGE = Gtk::Window PREFIX = gtk_window_
This makes gtk_window_new() become Gtk::Window->new() in Perl.
> The previous wrappers constructed perl classes (packages)
> for the various types available in Gtk, and made methods
> in the packages which called the real c functions with
> shorter names. Once the above perl code is possible to execute,
> going to this next level should be simple. All GtkWidget
> objects are derived from GObject, and all GObjects have
> a GType, for which there are functions in to get
> inheritance information. In a dynamically typed language
> like perl we could pre-build the packages as modules,
> or build them on-the-fly at run-time.
As far as I can tell there is no way to introspect methods (please
correct me if I'm wrong - I'd like to be this case).
So while you could create the packages at runtime, the objects blessed
into them would be somewhat useless... As they could be used via
properties and signals only.
> The methods which wrap the c-function-equivalents will have
> to translate pointers returned from the c library into perl
> objects of the correct type (the old version seemed to use
> a hashref with a single key/value (_gtk => pointer_value).
Again XS will do this translation for you. This is what typemaps are
for.
Using a hashref is actually a pretty neat idea. If the plain C pointer
was used the object would be opaque to the Perl side of things. So
subclasses would have nowhere to put object private data (I do know
about set_data/get_data - but those present other problems).
> This translation will involve construction of a new perl object
> when a pointer value is first encountered, and lookup
> of an existing perl object on subsequent encounters with the
> pointer.
>
> They will of course also have to extract the c-pointer values from
> the perl object ref when passing parameters into the method.
>
> When the C library wants a function pointer:
>
> As was pointed out previously on the list, getting perl to
> call C is a bit more straightforward than getting C to call
> perl back later, via a callback. I'll get into this after
> the XS stuff below.
>
> * SWIG and XS parsing the headers:
>
> There are two tools typically used to bind C libraries to perl,
> xs and swig. swig is built to work from library header files to
> produce a perl wrapper. With xs you code the c back-end for a
> perl module in a special c/perl hybrid language, but there is a
> script called h2xs which automatically produces xs code for you
> from C header files.
>
> Both h2xs and swig seem like they could do the trick, but both fail
> when parsing the gtk header files. Unfortunately, I can get neither
> of them work on the gtk headers. h2xs doesn't let you give it
> -I parameters to change the include path, but even after
> modifying the script to search the gtk directories, the underlying
> C::Scan module fails in some way when parsing the header. Swig also
> has issues.
>
> So I wrote my own parser for the gtk-oriented header files. If
> anyone wants to try to figure out why h2xs or swig do not work,
> and fix them, that would be great. I was more confident I could
> write a parser for the headers myself than I was that I could fix
> someone else's, so I did that instead.
>
All the bindings I've looked at use .defs file for generating their
stubs. This is not a bad idea as header parsing (which is rather error
prone) and the following handcleaning of the results, can be done just
once.
> * Where things are so-far for me:
>
> I have as script complete which uses pkg-config, gets a list of the
> libraries used by gtk on the system. I just finished it this morning,
> and will try to get it on my web site tonight.
>
> I run the header files used by gtk through the gcc preprocessor to get a
> clean super-header, and then scan the super-header for prototypes
> for every function in the library possible. Many function do not
> appear to have prototypes, and are possibly not part of the public API.
>
> Each prototype is parsed and a multilevel hash is constructed to
> describe each function. I just got the parser to not choke on a few
> exotic functions last night.
>
> * Here was my tentative plan for what to do next:
>
> 1. Extend the script to write the actual xs code for each function.
Such a script allready exists in the old binding.
Shouldn't need that many changes.
>
> 2. Test to make sure we can build the basic perl wrappers for the libs.
> (like Goran's code but without having to hand-write gtkperl_*
> wrappers)
>
> 3. Produce a module which will be directly "used" by the programmer.
> It should:
> . "use" the lib* modules.
> . query the GType system and build a perl inheritance tree.
> . each package generated should know its function prefix
> . AUTOLOAD should create class methods which are wrappers
> for underlyin c functions on the fly.
This is how the python binding do it - at least they did for gtk+ 1.
In Perl it doesn't make sense as XS will do it for you (better and
faster).
> 4. Ensure that the wrappers handle genral perl <-> c object
> translation. Creating a GClosure, or anything else with a C
> function pointer, out of aperl closure looked like it might take some
> work, but at first glance it looks like Goran's code is doing it.
A Perl closure seen from C is just a SV * (a CODE ref in Perl).
Arguments will need marshalling though...
> 5. Work on error handling, using the function prototype info
> to produce clear messages when wrong paramters are passed to
> the gtk wrapper.
|
