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/
pgpC3bzYFlVo5.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
