CashUtil and GnuCash libraries

Neil Williams linux at codehelp.co.uk
Thu Sep 8 17:21:20 EDT 2005


On Tuesday 06 September 2005 11:33 pm, Derek Atkins wrote:

OK, we were talking at cross-purposes and getting various levels of 
integration confused. Plus I misunderstood part of your reasoning. Sorry.

I still can't see that CashUtil should support loading the business objects 
(and file backend) separately from the 'core' objects at runtime or as a 
(redundant?) package but I think I can work with what you want.

> > gncInvoice goes into a library with Account etc.
>
> NOOOO!!!!!!  That's exactly what I *DO NOT WANT TO HAPPEN*

At the internal levels that GnuCash will use to link against the code, it can 
be as many individual libraries as needed - the coalescence happens at the 
next level. CashUtil will link against both sets of objects and handle them 
as if they *are* one when GnuCash can use them individually.

It's only natural that as the C files themselves are staying put, the files 
will be compiled into 'local' libraries according to those locations (rather 
than building libraries from scattered C files directly). These smaller 
libraries will have new names (to reflect the lack of the gnc-module method 
or scheme code) but retain most of the current contents. GnuCash will have to 
wrap the Guile/scheme around the small libraries itself (which I think it 
does already but can't be sure).

> > This 
> > allows GnuCash to link all it's GUI code against the objects while
> > CashUtil links all it's CLI code against the objects - from the one
> > object library.

I'm talking here of the final build rather than the Makefile.am in each 
individual directory. CashUtil can link two libraries where it currently 
links one - what I do not want is for CashUtil to be expected to load or 
unload certain libraries/objects at run time or necessarily support any 
'personal' / 'business' divide at compile time.

> So you've got libcashobjects that has the core engine objects, and then
> there should be a libcashbusinessobjects which is effectively
> libgncmod-business-core.

If it's the price of integration into the GnuCash source tree and it doesn't 
imply that CashUtil should support such a division itself, I think I can work 
with that.

> It was specifically designed to remain separate because we 
> want to be able to ship a version of GnuCash WITHOUT the business objects. 
> We WANT to be able to have a "gnucash-personal" and "gnucash-business"
> package.
(moving this snip to answer in one go)
> Oh no, it's been documented and discussed since I first wrote the
> business code
> years ago.  The reason is so the business code is separable.  So someone
> doesn't have to run with the business code..  So a packager could
> distribute the business code separately, in a separate package..  So a user
> who doesn't need the business code doesn't need to have it installed.
>
> It's a module in the same way that hbci and ofx are modules, and should be
> separable in the same way that gnucash-ofx and gnucash-hbci packages
> exist. The only difference is that there's no configure option to turn
> off the
> business objects, and few packagers actually separate it out.  But that
> doens't
> mean we should screw over those who do (or want to).

I had interpreted the complete lack of a 'method' for such a division in the 
CVS or final program as an indication that this was maybe a result of the 
previous (incomplete) modularisation of GnuCash. 

Other modules are explicitly coded to support such a division in configure - 
as you say, there's nothing like that for the business code. No conditional 
build, no option, nothing except the locations of the files and the library 
names. To me, it looked exactly the same as the other "LDFLAGS=-module" code.

I was unaware of any attempt at a non-business gnucash. IMHO such a split is 
neither particularly desirable nor useful in CashUtil.

This is because of how QSF handles partial books - without the limitation of 
the GnuCash file backend reliance on AccountGroup, QSF can handle any set of 
objects and it's easy to only work with those objects that are relevant to a 
specific series of queries whilst retaining a usable file. This is vital for 
data-mining and data freedom. The gnucash file backend was never designed to 
write out a file that had no accounts (let alone no group) but in QSF this 
was an absolute design requirement. (Hence the need to always merge QSF data 
into other GnuCash data!!)

> > There can be no code from business-gnome etc in with the business
> > objects. The business module - the current mix of object, backend and GUI
> > code - is completely incompatible with CashUtil.

That section remains and is still do-able. We are only talking here of linking
libcashbusinessobjects.la and libgnc-backend-bus.la from 
src/business/business-core and src/business/business-core/file respectively, 
with CashUtil. The rest of src/business must remain GnuCash only, as must the 
Guile/scheme code in -core and the gnc-module stuff in -core/file.

> > cashutil currently supports the Split, Trans, Account, GncOrder,
> > gncTaxTable, gncVendor, gncJob, gncInvoice, gncEntry, gncEmployee,
> > gncCustomer, gncBillTerm and gncAddress database table names. You can use
> > the names with cashutil -d and in SQL queries (as the table name) with
> > cashutil -s|f. Use '-d <database> --explain' to see the list of fields
> > within any supported database.
>
> I really don't want the business objects to live (in a library or a source
> directory) with the core engine objects.  I want them to be separate. 
> Can't cashutil learn to live with two sets of libraries?

I think it can, yes - at the low level of the source tree directories. When 
CashUtil itself is built, it will expect both sets of libraries and will 
register all objects in one operation. (All for one and one for all - object 
equality.)

> > A further distinction then follows as the ancillary logic expressed in the
> > current GUI is abstracted into the common libraries for CashUtil and
> > GnuCash to use together. So finally the common libraries include the
> > objects, the backend and the logic.

I'll put some flesh on this and re-post in a few days with a clearer plan of 
library names, file lists per library and some kind of diagram of how it 
might fit together.

> >> Please keep it that way.  GnuCash (and Cashutil) should work
> >> just fine WITHOUT the business objects loaded.

GnuCash can but I still think it's overkill for CashUtil. I don't intend to 
explicitly support such a division in CashUtil.

> > The business objects work fine within CashUtil and there's absolutely no
> > reason to take them out.
>
> I'm not asking you to take them out of CashUtil.  I'm asking you to
> keep them as
> separate libraries.

I meant by providing a lameduck version of CashUtil without them.

> > Sorry, CashUtil is sticking with one set of objects. It's FAR too late to
> > go springing something like this on me.
> >
> > GnuCash can have a distinction if you want, but CashUtil cannot.
>
> Hmm... I think we're talking cross purposes...  But whatever.  You're
> coding cashutil.  You're welcome to keep it in sync as a separate util ad
> infinitum if
> you wish.  Personally I'd like to see it integrated into Gnucash, which
> means it'll have to load the core objects and business objects separately
> from two libraries.

It can work with the division of the libraries but I can't see the point of 
actually implementing a separate load call in the frontend. I'll stick to 
multiple small libraries (always including the business objects) linked 
against the cashutil program at compile time.

-- 

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/20050908/d4bb70e6/attachment.bin


More information about the gnucash-devel mailing list