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

[Rachel Hestilow]

--=-DHpvnCxIJBxEdUitaJeb
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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:

Summary:
  With the new support for structs, opaques, and callbacks (callback
support yet to be committed), Gtk#'s code wrapper effectively supports
everything one would need in wrapping both glib-based and non-glib-based
libraries. To this extent, people are increasingly interested in using
the code generator for their own bindings. In order to accomodate these
new users, the code generation pipeline should be abstracted into its
own module.

Implementation details:

To be moved into gtk-sharp-generator (better, generic name would be
nice):
  * parser/*.p[lm].
  * generator/: This will be a build-time dependency, so perhaps it
should be made so that it can be cvs-included, I'm not sure.

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

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

What are you thoughts on this, mike? I can start work on it after I
finish up my applet/callback support.

-- Rachel




--=-DHpvnCxIJBxEdUitaJeb
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA9Xq8napOJdUj74F4RAtutAJ9VdRlQGqSqqR6Fh3VJiHOBEyvTgACfbg3U
84InVwf7iYIkl2r61njBRzU=
=pcQU
-----END PGP SIGNATURE-----

--=-DHpvnCxIJBxEdUitaJeb--