Re: Proposed plugin API for GCC

[David Malcolm <dmalcolm at redhat dot com>]

On Fri, 2012-03-30 at 15:08 +0200, Basile Starynkevitch wrote:
> On Fri, Mar 30, 2012 at 02:14:31PM +0200, Richard Guenther wrote:
> > 
> > Btw, how ugly is it to make this API grokable by swig?  Would that serve
> > the python plugin?
> 
> 
> An alternative would be to have either some easily parsable API definition
> (wwhich might be sort-of offered by Swig, but I'll bet that not in practice:
> we'll need to use weird Swig tricks), or some way of querying at runtime that API.
> 
> The important part in my view is that such an API should not be targeted to
> Python only. It should be usable by plugins coded in C++ (or in MELT), or in
> other languages.
> 
> Again, the GTK guys did a good work with their Gobject introspection layer,
> which is a meta-API providing that.

[I briefly worked on the Python 3 backend for GObject introspection,
fwiw]

Here's another proposal then: actually use GObject introspection -
provide a GObject-based API to GCC.

In this approach, GCC would gain a dependency on glib and gobject, and
expose its API via a .gir file.

Thanks to the existing backends, the API would then be immediately
available to Guile, Python 2 and 3, JavaScript, Ruby, etc (and my plugin
either needs a total rewrite, or becomes redundant, disappearing in a
libffi haze...).

For more information, see:
  https://live.gnome.org/GObjectIntrospection

This may be overkill, and the above has the warning "Note: GObject
Introspection is still in development" (I've spent far too long
debugging libffi crashes - due to bogus type signatures - in other
projects to be keen on it, fwiw).

> The point is that GCC will stay complex, and any API will by necessity be
> huge. We have to know that and to ease it uses (e.g. to facilitate the
> embedding of several scripting languages, not only Python).
> 
> So it really would help if the API is documented and mechanically queryable.
> 
> A traditional manual glue code is not enough.
> 
> (And there might be memory management issue; we have to specify very well
> when a GCC data should be released, and by whom. I feel that Ggc is part of
> the solution).
Object lifetimes could be a nuisance: GObjects are reference-counted
iirc.  I don't know if that would be a problem for MELT.

Dave