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
