Wishes to the new G-Wrap maintainer?

[Andreas Rottmann]

Derek Atkins <warlord at MIT.EDU> writes:

> Andreas Rottmann <a.rottmann at gmx.at> writes:
>
>> In fact, it has also got another re-write by me :)
>
> Great... just what we need, yet another re-write...  ;)
>
>
Well, IMO, the design is now clearer and is easier to extend
(multi-language support would have been a real hassle with the old
G-Wrap code).

>> I might add Python support if I'm bored during the summer holidays; it
>> would be a nice proof that the architecture of the 1.9 series is
>> flexible enough for multiple target languages.
>
> I'm not sure whether python or perl is more important as a second
> language...  YMMV.  :)
>
I know the Python C API and don't like Perl as a language very much,
so the choice is clear for me :)

>>> On my g-wrap wishlist, in order:
>>>
>>> 1) proper guile-1.6 code generation (don't generate code that uses
>>>    deprecated functions, e.g. change scm_{,un}protect_object to
>>>    scm_gc_{,un}protect_object if building with guile-1.6.
>>>
>
>> Fixed in 1.9.0 (released today). Unfortunatly, 1.9 and 1.3 wrapsets
>> are incompatible; an 1.3 compatibilty layer or conversion tool is
>> planned, however.
>
> *sigh* -- so we need to port all our spec files?  UGGH!
>
Maybe you can replace them by .defs files, see below.

> What was wrong with the old interface?!?
>
Since all the G-Wrap internals were rewritten, the 

> If we need to do that, it might be easier for us to move to swig.
> Seriously.  All we need to do to use swig is modify the header files
> and add the following code:
>
> #ifdef SWIG
> %module mymodule
> %{
> #include "myname.h"
> %}
> #endif
>
This will only work if the header file is simple.

> That's it.  If your new spec file isn't that easy, there's no (or
> little) reason to move to g-wrap-1.9.  Well, there's one reason: so we
> don't need to provide an API compatibility layer for our existing
> scheme code.
>
Well, in light of GnuCash moving to GNOME 2, you might use
h2def.py. This script parses the headers and spits out a .defs file
that can then be loaded by G-Wrap. Writing a wrapset for such a .defs
file is a breeze:

(define-class <atk-wrapset> (<gobject-wrapset-base>)
  #:id 'gnome-atk
  #:dependencies '(standard gnome-glib gnome-gobject))

(define-method (global-declarations-cg (self <atk-wrapset>))
  (list
   (next-method)
   "#include <atk/atk.h>\n"
   "#include <atk/atk-enum-types.h>\n"))
  
(define-method (initialize (ws <atk-wrapset>) initargs)

  (next-method ws (append '(#:module (gnome gw atk)) initargs))

  (add-type-alias! ws "AtkState" 'long-long)
  
  (load-defs ws "gnome/defs/atk.defs"))

>>> 2) port to glib2/gtk2
>>>
>> 1.9.0 has dropped the GLib binding; it is now provided by guile-gnome,
>> which targets GLib/GTK+ 2. The 1.3/1.4 line is mostly stalled, but I
>> might release a 1.4.0 with a few bugfixes and targetting GLib 2.0, for
>> the sake of GnuCash (guile-gnome, the other major project that uses
>> G-Wrap, has already switched to the 1.9 line).
>
> This is yet another reason for us to move to swig -- adding
> dependencies is a BAD THING.  Don't split up functionality into
> multiple packages, combine them into bigger distributions.
>
Sorry, but I disagree here. Modularity is good, and there is no reason
why to include wrapsets for a random library in a wrapper generator
(other than historic, maybe).

> It's a pain in the ass for users to compile hundreds of small
> packages versus a handful of large ones.
>
Users should be using a distribution which provides package management
(and not compile packages at all).

> If this is the case we may just pull 1.3.4 into our tree, fix the
> problems that currently exist, and just subsume the code and ignore
> future g-wrap.  Seriously, all we need is glist and gslist.  If
> g-wrap cannot continue to support that natively then it's another
> reason to ignore the work.  Seriously.
>
Well, I consider it out of the scope of a wrapper generator to come
with bindings for random libraries. There is guile-gnome and the
responsibilty of wrapping GLib, GTK+ and other GObject-based libraries
clearly lies there.

>>> 3) improved configure script that actually works, and tests for slib
>>>    and qthread support.
>>>
>> OK, I'll add an SLIB check. Isn't qthreads an Guile-internal thing?
>
> Yes and no..  There were problems building g-wrap if guile wasn't
> compiled with qthreads.  IIRC it was a configure error trying to
> determine the length of a long, or something like that.  It was quite
> a strange failure, but inevitably it was due to guile not having
> qthreads..  Recompiling guile with qthread support always fixed the
> problem.
>
G-Wrap has (since some time) a bug tracker on savannah[0]. Could you file
a bug for this, so I don't forget?

>>> 4) proper co-existence with older g-wrap (i.e., versioned scheme files
>>>    and/or versioned directories, as well as properly versioned .so files).
>>>
>> Yeah, that's something to think about. I don't know however, if
>> parallel-installabilty of the development files (as opposed to the
>> runtime, which should be co-installable definitly) is easily feasible.
>
> Fair enough, so long as the files are internally consistent and will
> throw an clearly defined error if there is a version mismatch.  Also,
> it WILL be necessary to have multiple versions if we move the gnucash
> g2 port to a new version of g-wrap.  Us developers are working on both
> versions at the same time, meaning we need both development
> environments co-resident.
>
OK, if the GnuCash people decide to actually use G-Wrap with their G2
port, i'll try to make it co-existable.

[0] https://savannah.nongnu.org/bugs/?group=g-wrap

Andy
-- 
Andreas Rottmann         | Rotty at ICQ      | 118634484 at ICQ | a.rottmann at gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

To iterate is human; to recurse, divine.