Hi,
I did try to generate C++ bindings for gobject-introspected
libraries. However, all I achieved before losing interest was
a gir parser written in python (you can see advertisement of
this in the list's archives).
I don't understand what you mean by 'why don't we use it in
mm projects instead of writing perl scripts'.
gobject-introspection provides two products for each library:
a XML file (gir) containing the definition of the API, and a
typelib where that definition is compiled (platform
dependent). For mm projects the gir files could be really
useful, and we could replace the current set of perl scripts
with a set of programs/scripts that parse the gir files and
generate the .defs files from them. But you cannot avoid
writing something to parse the XML gir files; note that
typelibs are platform dependent and therefore are not suitable
for our needs.
In my opinion, and I think in the opinion also of more
people, a first step would be to generate the .defs files from
gir files, writing a parser in perl, python, ... whatever.
A second step could be to, in addition to .defs files,
generate also the .hg and .ccg files from gir files. I think
this needs to add some flexibility for inserting hand-written
code, since APIs are not always that good and we may want to
make modifications, event to make them more C++-ish.
So, conclusion: mm projects could take advantage of
gobject-introspection for generating .defs files and even .hg
and .ccg files. We shouldn't, however, replace all that has
been done and come up with new API conventions; i.e. we
shouldn't get rid of RefPtr, GLib::Object, ... However,
gobject-introspection is not a panacea: in contrast with what
happens with interpreted languages, we still need to provide
separate packages for every wrapped library, i.e. we obviously
cannot provide dynamic bindings using typelibs.
As far as I know, someone wrote a Go bindings generator
from gobject-introspection; and also for Java.
I recently created a project on github (it is empty
nowadays) to write a gir parser that can output .hg and .ccg
files. This could be useful for wrapping, for example, new
classes. Instead of writing a bunch of
WRAP_METHOD/PROPERTY/SIGNAL statements by hand, that could
be easily automated from gir files. Therefore, if you decide
you want to go with gobject-introspection, please do not
hesitate to contact me if you need help :)
Best regards,
Juan.
