Re: gobject introspection
- From: Havoc Pennington <hp redhat com>
- To: Michael Lawrence <lawremi iastate edu>
- Cc: gtk-devel-list gnome org
- Subject: Re: gobject introspection
- Date: Tue, 01 May 2007 14:19:13 -0400
Hi,
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
http://bugzilla.gnome.org/show_bug.cgi?id=363228
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)
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
itself
- Output (or keep in-memory parse tree, as appropriate) the resulting
IDL
- 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.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]