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
Rob Taylor started working on it again, see
> 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
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.
- 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.