Re: Time to talk about g-wrap

[Rob Browning <rlb at cs dot utexas dot edu>]

Ariel Rios <ariel@linuxppc.org> writes:

> But if you could send something like a stupid documentation would be
> very helpful. SOmething like:

You can get the latest version from ftp.gnucash.org/pub/, though it
still lacks documentation.  I'll try to write something up soon (maybe
tomorrow if I'm feeling better), but in the mean time, you might want
to look at gnucash's gnc.gwp file.

Note, though that I gnc.gwp is not the naming convention I'd intended
people to use in the future.  I'd planned for something more like
gnucash-spec.scm since "spec" files are not just scheme code.  That
way you can load the spec with

  (use-modules (foo bar-spec))

(or just '(load "foo/bar-spec.scm") if you're not generating modules).

and then you can load the resulting module with

  (use-modules (foo bar))

or similar.

Note that I'm not stuck on the way things currently are.  That's just
the best I could come up with mostly on my own, and in consultation
with a couple of other gnucash developers.  I'm sure there are things
that can and should be changed for the better.  Also, I suspect that
there are things that g-wrap doesn't handle that you might need it to.

In any case, I'll write a summary of the current state that hopefully
hits all the high points.  If I'm lucky I'll be able to dig up one of
the long emails I've already written on the subject and enhance it
rather than starting from scratch :>

> My biggest concern is to keep usng defs files.  I have thought to
> write macros to map defs files so a macro of the type (define-func
> gtk_foo_new) can translate unto the corrsponding g-wrap...

Well, if the defs files are scheme forms (that's what I recall
anyway), then it should be easy to just write either a set of macro
statements, or perhaps just a simple recursive read/writer function
that can perform the translation.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930