[Gtk-sharp-list] Proposal for seperating out code generation

[Mike Kestner]

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
>     manner.)

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)
>     gtk-symboltable.xml.

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)
type names.

> 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 <mkestner@speakeasy.net>