Wishes to the new G-Wrap maintainer?

[Derek Atkins]

Andreas Rottmann <a.rottmann at gmx.at> writes:

>> #ifdef SWIG
>> %module mymodule
>> %{
>> #include "myname.h"
>> %}
>> #endif
>>
> This will only work if the header file is simple.

True..  But it does handle the vast majority of the work.  I just
tried this on src/engine/Account.h.  It mostly worked, but I still
have to handle the glib types (gboolean, gint, gint64, etc) and a few
gnucash structures that are passed by value (e.g. gnc_numeric).

> 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:
>
[snip]

Will this script handle such things as gnucash's gnc_numeric type?

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

This is why I prefer KDE/Qt over GNOME.  Yes, modularity is good.
Separate shared libraries for modular functions are good, to a point.
But there's a limit.  At some point you just need to say that enough
is enough and combine distinct but mutually-required pieces into a
single package.  For example, gobject is part of glib.  This is good.

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

You're being very linux-centric here.  Have you ever used Solaris?
IRIX? AIX? HPUX? Tru64?  Show me where I can find prebuilt packages
for these (ok, Solaris packages exist for many things)...  Now, show
me a package manager where not only binary packages but all the
dependency handling is done.  Don't worry, I'm not holding my breath.

My point is that while modularity is good, tons of tiny little
packages is not.  C.f. dependency hell.

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

Sure.  It'll be filed shortly.

> OK, if the GnuCash people decide to actually use G-Wrap with their G2
> port, i'll try to make it co-existable.

Thanks.  Right now we're still using g-wrap 1.3.4 (which surprisingly
still works, even with the old glib bindings).

I don't think we've got a strong opinion at this point, but I can
assure you that re-writing all the spec files is a deterrent to
upgrading.  Now, if upgraded spec-files magically got sent to
gnucash-patches, that might change my mind.  :)

-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