Derek Atkins <[EMAIL PROTECTED]> 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 | [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
The best way to accelerate a Windows machine is at 9.81 m/s^2
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
