Wishes to the new G-Wrap maintainer?

Derek Atkins warlord at MIT.EDU
Wed Jun 30 12:10:41 EDT 2004


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

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

>> 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!
What was wrong with the old interface?!?

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

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.

>> 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.  It's a
pain in the ass for users to compile hundreds of small packages versus
a handful of large ones.

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.

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

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

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available


More information about the gnucash-devel mailing list