Linking the shared library FOO.la against the loadable module
linux at codehelp.co.uk
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:
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
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
In fact, recently, that's been extended to SX, commodity and Group.
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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050906/4703664d/attachment.bin
More information about the gnucash-devel