Derek Atkins <[EMAIL PROTECTED]> writes:
> Andreas Rottmann <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL
PROTECTED]
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.
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
