The following is just a summary of my ideas on how CashUtil could share financial logic with GnuCash - with as few changes to the source tree as possible and retaining as much CVS history as possible (seeing as we are using CVS not subversion).
None of this is urgent or fixed, I'll be using CashUtil as a QOF test routine for some time yet. It's just that when work commitments reduce the time for writing code (as this week), I tend to plan the next stage in the quiet times at work. With the exception of the files to be moved into lib/qof, this *could* leave existing .c and .h files in their current locations, so preserving CVS history for the business objects, the v2 backend etc. The full list of files involved so far, is here: http://www.linux.codehelp.co.uk/cashutil/gnucash.html (The tables list those files in src/engine that are part of QOF, those across the G2 tree that are needed currently by CashUtil with their current GnuCash (G2) locations and those in src/engine that are not needed by CashUtil (including those that cannot be part of CashUtil) or where CashUtil locations are undecided.) The GnuCash XML v2 backend is also required but not listed explicitly. By building that library in the existing tree, I believe it can follow the pattern of the src/engine objects and src/business/business-core objects: Build one library in each location and then combine the two libraries into one for use with CashUtil and/or GnuCash. Current hypothesis: 1. Those files that redefine QOF functions, defines or types with GNC prefixes can be retained by GnuCash (possibly deprecating the old names?) and ignored by CashUtil. I'd patch any calls in the files to be shared with CashUtil that use the gnc prefix. 2. CashUtil is testing with a single object library that instead could be formed from two shared libraries, one built in src/engine and one in src/business/business-core. 3. The G-Wrap files can still be generated in situ - as long as they are then compiled into a separate library that is not linked against CashUtil. 4. Scheme specific code could be treated like the G-Wrap code. 5. Budgets may or may not end up in CashUtil - it may not be appropriate to port Budgets to a CLI. (This would be non-trivial to incorporate into CashUtil as budgets are not QOF objects - Personally, I don't see budgets being that useful in a CLI.) Comments? 6. The gnc-engine module would be GnuCash only - if it is still used. It could incorporate the same libraries as CashUtil with the extra code from these excluded files. 7. The files from gnucash/src/engine that are also in QOF would be moved (at some future date) from src/engine into lib/qof and later removed completely when GnuCash links against QOF as an external library. 8. Further changes in the GnuCash XML v2 backend (possibly split in the same way as the object library between src/backend/file and src/business/business-core/file) will remove the need to load the current backend using GnuCash specific code - it could be loaded in the same manner as QSF. (This will be necessary to use QOF as an external library.) 9. Using the business objects as a separate library could offer the ability to retain the current Business module for GnuCash whilst integrating the business objects tightly into CashUtil. Note: None of the above has yet been tested in a real tree and some of it may never work, it's just a set of ideas. It's just a starter. Feel free to pick holes (constructively). :-) To partially answer Derek's earlier question, I also have a better idea of what is stopping CashUtil from currently being built within the GnuCash tree (most awkward first): a. qofsession.c uses GnuCash #define's to load the v2 backend. The system for loading that module isn't likely to be supported by CashUtil, instead I'd like to make the v2 backend into the same type of library as QSF and load it via the same mechanism (within CashUtil AND GnuCash.) b. Some way of handling gnc-trace so that it knows which package it is tracing, as this will be a QOF file. c. Adjustments to the Makefiles to remove Scheme and G-Wrap source from libraries to be shared and create new libraries that contain this code for GnuCash to use. d. gncCommodity. This is not a complete list, just issues I have found so far - some of these are admittedly trivial / expected. I'm beginning to wonder what I've started and whether there's sufficient time to get it ready for G2! The CLI is an eagerly awaited feature. Some users could come back to GnuCash once a CLI is available. I want to get it as usable as I can and as reliable as possible. It would be better to release G2 and then the CLI as a part of 2.1 rather than release a sub-standard CLI that disappoints such expectant users. However, I will try to get it ready for G2. If anyone else fancies joining myself and Daniel on this task, please contact me! (please?!) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpR0gL1P3vpd.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
