Linking the shared library FOO.la against the loadable module

Tue Sep 6 18:06:56 EDT 2005

On Tuesday 06 September 2005 9:37 pm, Derek Atkins wrote:
> > I also appear to have solved the GTKHTML problems of earlier (principally
> > by removing an old 1.8 package - so the environment variable hack was a
> > waste of effort!)
>
> Sorry, which gtkthml problems?

CVS G2 hadn't been building on OSX for some time due to confused gtkhtml 
errors - it didn't pick up that an old version was installed that broke the 
build as it was being found before the required version.

I've now got a similar problem - it's using gtkhtml1.1 and getting confused. I 
now need to build the 1.8 tree from CVS as well as the G2 tree because 
neither can live with the binary fink version. Thing is, I need a reliable 
installation on one box for my own GnuCash financial records. Looks like I 
won't be building G2 on OSX anytime soon.

> > So that would make:
> > libqof1, libcashobjects.la, libgnc-backend-file.la, libcashlogic.la (a
> > new one).
> > That would replace the entire contents of:
> > src/engine/
> > src/backend/file/
> > src/business/business-core/
> >
> > and various, as yet undetermined, sections of the GUI code into a
> > shared logic
> > library (shared between GnuCash-GUI and CashUtil).
>
> PLEASE PLEASE PLEASE PLEASE PLEASE keep src/business SEPARATE.

? Hang on a tick. I can go back through the archives if you want, but this is 
old news, Derek!

> DO NOT 
> require src/business to get integrated into src/engine.

It's not. Please take a good look at the breakdown on the CashUtil site, 
gncInvoice goes into a library with Account etc. The file stuff goes in with 
the other file backend stuff. The engine goes into QOF. Feel free to take a 
look at the tarball too:
src/
src/objects/
src/backend.
src/test/

Even the test routines are collected as one.

Not much is going to be left of what is now src/engine - the list is on the 
cashutil website but consists mainly of (redundant) guile/gwrap code and the 
Budgets code that doesn't yet fit well with a CLI, even though it's not 
actually GUI dependent. The other parts are linked against libcashobjects.la 
(a genuine shared library, not another module). 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.

There's been a table on the site for weeks listing exactly where each file 
comes from and which objects are supported. It was put up specifically 
because of discussions on this list.

"The existing financial objects, including the business objects, need to be 
collated into a single library that can be shared with CashUtil."
"The existing GnuCash v2 XML backend, including it's business object handlers, 
also need to be collated into a single library."

These are BOTH now done. 100% complete, tightly integrated and bound.

The profusion of #ifdef's are an indication of the coalescence of the 
disparate sets of objects and backend components into logical wholes.

As I've always said, the C files themselves can almost certainly stay exactly 
where they are (for CVS history purposes) but the libraries are different - a 
clear distinction between the objects and the UI code. 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.

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.

In fact, recently, that's been extended to SX, commodity and Group.

http://linux.codehelp.co.uk/cashutil/

http://linux.codehelp.co.uk/cashutil/gnucash.html

A further distinction the 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.

> It's a separate 
> set of modules
> for a REASON.

(an undocumented reason?)

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

Eh? When was this decided? Why? Since when did this become a problem of FOUR 
units? I've built CashUtil for two - ALL the objects together and a single 
file backend to complement QSF.

The business objects work fine within CashUtil and there's absolutely no 
reason to take them out. 

Please don't say this is something else you missed in the LONG list of 
discussions on this whole thing. It has been this way on the CashUtil website 
since it started. It clearly states that gncInvoice will be in CashUtil just 
like Account. There is no division available - conceptually or 
programmatically.

This is a small utility program, not a toolkit. It doesn't have the 
wherewithall to go around loading objects on demand or even at runtime. The 
backends are enough to deal with and most of that is done via QOF.

There are excellent reasons for having options in the choice of backends - 
there are no clear reasons, in a program this small, for having gncInvoice 
loaded at runtime and Account loaded at compile time. Complete overkill and  
unnecessary complication of the UI.

I see no purpose in even writing CashUtil without the business objects tightly 
integrated. There is precious little overhead and no reason to partition the 
list of supported objects. There is absolutely no reason to support separate 
business objects in such a small program - they consist of over 30% of the 
code!

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. 

-- 

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/20050906/4703664d/attachment.bin