Re: gobject introspection

On 5/1/07, Havoc Pennington <hp redhat com> wrote:

Michael Lawrence wrote:
> I am wondering what is happening with GObject introspection. It seems
> that it has been in the works for some time now but that development has
> stalled.

Rob Taylor started working on it again, see

Ok thanks for pointing that out.
The original bug is here: 

> 1) What are the overall goals of the project? From what I gather the
> goals are twofold:
>   a) To define a common representation (GIDL) for GObject-based API's.
> Binding generators can then be ported to use a standard format rather
> than the current assortment of defs files, GAPI, etc.
>   b) To support run-time introspection by accessing a binary blob of
> metadata.

Combining a) and b) I would say part of the goal is run-time binding
generation, i.e. right now most of the bindings involve a couple megs of
static function stubs, ideally this could be replaced with perhaps a
couple hundred K of generic code that built binding objects on demand
(much as e.g. dbus-python works)

My thoughts as well.

> 2) How is the GIDL/metadata generated? The Vala project has some scripts
> that generate GIDL from header files. This is obviously a difficult
> task, because things like memory management, in/out parameters, etc
> cannot be automatically derived from header files. Thus, human
> annotation is necessary.

My preference is this pipeline:
  - Scan headers (or code in other language) and generate a base IDL
    file (or in-memory parse tree)
  - Allow "magic comments" in the headers to modify the IDL that would
    otherwise have been created. Similar to gtk-doc comments.

I made some suggestions along those lines a while ago on the GtkDocFuture page: It's at the bottom of the page.


  - Allow a "merge file," a lookaside IDL file that overrides or adds to
    the scanned IDL - similar to magic comments but not in the C code
  - Output (or keep in-memory parse tree, as appropriate) the resulting
  - Output a binary type lib containing the same information

A pipeline should also be possible where you write the IDL file first
and then a C header is generated. This is useful when the IDL file is
part of a spec or shared between multiple apps.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]