[Gtk-sharp-list] Proposal for seperating out code generation
18 Aug 2002 13:41:24 -0500
On Sat, 2002-08-17 at 15:16, Rachel Hestilow wrote:
> Today on IRC, two different people asked me about using the Gtk#
> infrastructure to wrap new libs. So I figured it's time I wrote this
> proposal for seperating out the generation stuff:
I have no issues with trying to make it more easily reusable, but I
don't want to move it to a separate module.
> Code changes in generator:
> * Signal generation needs to realize when it can't stick signals into
> the "right" assembly (like, if said assembly isn't being generated)
This is just an optimization that can avoided when multiple namespaces
aren't being generated.
> * XML file should be split up into per-namespace files. Generator
> should accept additional XML files as "dependencies" for the current
> assembly (we need the full hierarchy to create code). Bindings
> should install their XML files to a datadir so that other bindings
> may depend on them. (This is done with .defs files too in a similar
Yeah, good idea.
> * SymbolTable hacks should be loaded at runtime from XML files. Once
> multiple files are accepted, it will be easy enough to have
> (automatically generated) gtkapi.xml and (hand-written)
Based on a discussion with mmarker on IRC, maybe this could have helped
him avoid doing his hack/slash job for glgen.
> * Introspection mapping needs to be fixed to be generic:
> The mapping table should be extendable. Wasn't the final decision
> on IRC that we put the registration code in wherever the assembly
> has an "init" func? (Gnome.Modules, Gtk.Application, etc).
I did it the simple way, because I discovered the beauty of
Activator.CreateInstance() with fully qualified (including assembly)
> Glib is moved to its own module
> There are an increasing number of gobject-based projects out there,
> such as gstreamer, that would only really depend on glib-sharp.dll. This
> module wouldn't even need code-generation because the only stuff in
> generated/ is signals (see my earlier point.)
Nah. Let's just start installing the generator and parser. If any
purists are offended enough by the presence of gtk-sharp.dll, they can
add a configure flag to stop the make at glib.
Mike Kestner <email@example.com>