Wishes to the new G-Wrap maintainer?

[Andreas Rottmann]

Derek Atkins <warlord at MIT.EDU> writes:

>> 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?
>
Well, you'd probably have to add a bit of extra code telling G-Wrap
how to actually wrap it, since it doesn't support structs (maybe
support could be implemented). h2def.py will just spit out S-Exps that
describe the API, e.g.:

(define-method set_flags
  (of-object "GIOChannel")
  (c-name "g_io_channel_set_flags")
  (return-type "GIOStatus")
  (parameters
    '("GIOFlags" "flags")
    '("GError**" "error")
  )
)

>> 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.
>
G-Wrap and GLib bindings have no mutual dependency (GLib and GObject
don't either, but they are much more closely related).

>>> 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.
>
Yeah, you've caught me :)

> 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.
>
What do you mean by "all the dependency handling"?

>> 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.  :)
>
I know that rewriting all those .spec files isn't really an option for
GnuCash. I'll try to come up with a conversion tool.

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

The best way to accelerate a Windows machine is at 9.81 m/s^2