test routines

Derek Atkins warlord at MIT.EDU
Tue Aug 16 10:45:31 EDT 2005


Quoting Neil Williams <linux at codehelp.co.uk>:

> The guile bindings at this stage would only be removed from the *test*
> routines - I won't change the structure of the actual modules until you've
> had a chance to test my proposed patch.

Yea..  that seems to make sence to me..  At least from within the QOF 
code. Even once it's spun out the scheme bindings should still be 
tested from
GnuCash.  Unless QOF decided to ship the guile bindings...

> In qofbackend.c, the QofBackend struct contains an #ifdef:
> #ifdef GNUCASH_MAJOR_VERSION
>    /* XXX remove these */
>    be->fullpath = NULL;
>    be->price_lookup = NULL;
>    be->export = NULL;
> #endif
>
> When QOF is spun out, these need to be relocated into the FileBackend struct
> (as I've already done) if they are going to remain in use. The todo item for
> this is that part of that final patch will have to restructure the modules
> into shared libraries that expect to find price_lookup in gnc_be rather than
> be.

Oh.  I see.  yea, this should probably be fixed..  Unless we change the 
pricedb
to be a QOF object ;)

> /* export and price_lookup have been moved but this
> 	section is not used yet - it is in preparation for
> 	CashUtil and an external QOF library. */
> 	gnc_be->export = gnc_file_be_write_accounts_to_file;
> 	gnc_be->price_lookup = NULL;
> (gnc-backend-file.c)
>
> My patch today includes temporary #ifdef rules so that CashUtil can build the
> file without the customised QofBackend struct. Those will be removed later.

*sigh*  We do have a lot of special-casing, don't we?  :(

>> >             and
>> > iso-4217-currencies.c which CashUtil cannot generate from the scheme.
>> >
>> > I'll work on gnc-pricedb.c but is there a better way of handling
>> > iso-4217-currencies.c?
>>
>> I don't understand what's wrong with the current iso-4217-currencies.c
>> generator.  It's a self-contained guile script.  Think of it in the
>> same way as
>> a self-contained perl script.  Would you object to a perl script to
>> generate the currencies code?  If not, then why object to a guile script?
>
> So it produces no guile or g-wrap dependencies? Will it run on a base system,
> something that say only has the CLI version of emacs? Are there systems with
> Glib but without scheme?

There is a build-time dependency on /usr/bin/guile.  There is no dependency on
g-wrap, and there is no runtime dependency on either guile OR g-wrap.

> I didn't realise it was self-contained.

You didn't ask ;)

> I only raised this as I expected it to raise a dependency in CashUtil on
> Guile/G-wrap via a dependency on Scheme.
>
> If it'll work without any GUI/Guile/G-Wrap dependency then I'm happy.

There is no runtime dependency.  It's just a guile-script used during 
build-time
to generate the set of currencies; it's a way to simplify the 
generation of all
that code.  Indeed, it may not even be a build-time dependency; it could just
be a "make dist" dependency...

I can't think of many development systems that don't have 
/usr/bin/guile..  And
even then the runtime systems wont need it.   That should be good enough,
right?

-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