test routines

[Neil Williams]

On Tuesday 16 August 2005 2:53 pm, Derek Atkins wrote:
> Quoting Neil Williams <linux at codehelp.co.uk>:
> > This, I hope, will also fix a number of test failures in G2 - maybe even
> > test-lots.
> >
> > :-)
>
> Uhh.. maybe.. maybe not..  It's unclear whether the test-lots test failure
> is due to a bug in the test or a bug in the code.  I don't know the
> cap-gains code
> well enough to actually have a good answer for that.

I'll at least try to clarify where the failure arises.

> > I'll be removing all the guile code from each test routine that
> > currently uses
> > either the engine module or the business module or directly interfaces
> > with the GnuCash v2 XML backend - i.e. the test routines that CashUtil
> > can use - in preparation for the libcashobjects.so and
> > libgnc-backend-file.so replacements (that CashUtil already uses).
>
> Hmm..  I need to think about this some more.  In the QOF code there's no
> guile bindings, so I think that's okay to remove the scheme tests from
> there.

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.

> > Remaining problems in the G2 source code that are preventing CashUtil
> > from building currently include gnc-pricedb.c (uses a customised
> > QofBackend (price_lookup) that only builds within the GnuCash tree)
>
> eh?  Why does this only build in the gnucash tree?  I dont understand the
> problem here.

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.

/* 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.

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

I didn't realise it was self-contained.

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.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050816/e8b10fe7/attachment.bin