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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
