Removal of

Derek Atkins warlord at MIT.EDU
Thu Jul 21 16:59:49 EDT 2005

I think there's a disconnect..  You're talking about packaging.
Josh is talking about source code.  You're both right.  :)

Personally, I'd like to see the most amount of code reuse
without code copying.  Yes, QOF is external and eventually
we should just use that.  But I do NOT believe that we should
rip out the core gnucash objects into their own source tree
build.  They can be their own binary package, but the source
should be in one and only one tarball.

- I'd like to see Cashutil folded into the gnucash source tree.
- I'd like to see the gnucash source tree "fixed" to handle
  cashutil.  This may require moving libraries around a bit,
  or it might not.
- I'd like to see the "accounting logic" moved out of the GUI
  and into an intermediate library.  However this should still
  be part of the gnucash source tree.  Note that this might be
  challenging to do "right", because lots of input verification
  can be.. challenging..  to do in an abstract way.
- I'd like to see the packaging (RPMS, .debs, etc) fixed to
  provide multiple packages so someone could install cashutil
  without installing gnucash-gtk.

I think this would solve everyone's issue.

In the short term, is there really a problem installing cashutil and
gnucash simultaneously from the same source tree?


Neil Williams <linux at> writes:

> On Thursday 21 July 2005 3:11 pm, Josh Sled wrote:
>> > The dependencies would sort out the rest, gnucash-common would be a
>> > dependency of both, along with QOF. Installing either would draw in
>> > gnucash-common and QOF anyway. The other dependencies (Gtk+ etc.) would
>> > be gnucash-only.
>> gnucash != gnucash-gnome-frontend.
> OK, I tend to consider the CLI as just CashUtil, then there's QOF (which I'd 
> like GnuCash to use as a separate library by then) and if CashUtil is going 
> to use all the logic inherent in the current GnuCash G2, as well as the 
> current backend (+/- replacement), then the abstraction of the current UI 
> logic into it's own API that is shared with CashUtil is going to mean that 
> the GUI will be a front-end for the shared libraries behind it.
> That is nowhere near where it is now, it's how I'd like it to be in the 
> future. However, it is not a huge departure - GnuCash already uses a host of 
> internal libraries. All I'm suggesting is a reorganisation of those libraries 
> to put the financial logic alongside the objects in a library that can be 
> used by the CLI. If that works, then the CLI can be folded into the GnuCash 
> source tree.
> The CLI and the gnucash-gtk front end would each be built against QOF and 
> another library that contains:
> 1. All existing objects, business or otherwise.
> 2. Abstracted logic from what is currently the UI in a form that both programs 
> can use.
> 3. The current gnucash xml v2 backend, including business object handling.
> Each would have their own code to express:
> 1. Their own UI, Gtk for one, CLI for the other.
> 2. Suitable error message handling according to the UI, dialogs vs stderr.
> 3. The GUI would keep all the reports and tree model.
> Once I've been able to demonstrate to myself that this could work, only then 
> would I consider folding CashUtil into the GnuCash source tree - it would be 
> natural then to share the new library that would be created by the fold as 
> well as share the source code. Then I would finally be free from manually 
> copying source files between projects!
> :-)
>> I guess that's the misunderstanding... you keep calling the
>> gnome-frontend "gnucash" and all the non-gui-related stuff
>> "gnucash-common", as the debian packages are that way.
> The gnucash-common in Debian, as Thomas pointed out, is an architecture thing 
> - not a UI/logic thing. It actually has nothing to do with the source tree 
> and everything to do with i386 vs SPARC etc.
> I thought of gnucash-common from a source perspective. It may not turn out 
> that way. It may turn out to be a financial logic library, internal to 
> GnuCash and CashUtil, with it's own API. 
>> I just don't 
>> conceptualize it that way, since the source isn't
> It's a lot of work to reconfigure the source to allow this to happen. It's 
> largely a case of removing all '#include's that reference private headers and 
> replacing the calls with an API (leaving function either unchanged or 
> enhanced) and switching files/functions around to make it easier to modify 
> the Makefile rules to build the same code into differently structured 
> libraries that better suit the logical divide between GUI and CLI.
> Building the CLI as a separate project will allow me to identify those 
> functions that are necessary for the proper logic in dealing with current 
> GnuCash data in a CLI environment. Initially, the CLI will have limited 
> financial logic and this is a weakness that is likely to confuse users and 
> restrict the use of the CLI. Only by abstracting the logic from what are 
> currently UI source files can I incorporate that logic into a CLI that can be 
> built without a GUI environment.
>> and I don't use 
>> debian.
> :-)
>> > > I don't know if we need yet another layer of
>> > > gnucash-common (though cleaning up some of this legacy stuff would be
>> > > nice).  We definitely don't need a seperate *package* of
>> > > gnucash-common.
>> >
>> > engine goes into QOF.
>> > app-utils and core-utils probably into gnucash.
>> > the objects and business-core go into gnucash-common.
>> Maybe mis-reading you, but I don't see how the gnucash engine concepts
>> go into the QOF package...?  I see [all in src/]:
> The gnucash engine IS QOF and vice versa. Each qof_ function is part of 
> libqof1 and gnucash can run using QOF as an external shared library. There 
> are no qof* functions outside QOF. Take a look at the source of QOF and 
> you'll find all the files are common. When GnuCash eventually uses QOF as an 
> external library, only the QOF objects (like Account and gncInvoice) need to 
> remain in gnucash. CashUtil abstracts this further by putting those objects 
> into a common library along with other ancillary logic sources that are 
> currently spread over the entire tree.
>> * {engine,{app,core}-utils,register/core,reports/core,...} => gnucash
> No. Nearly everything src/engine/qof* and src/engine/gnc* is QOF. Gnucash can 
> run quite well using the libqof1 library to provide these. In some ways, it 
> already does as the engine code is built into an internal library. By making 
> that internal library interchangeable with libqof1, gnucash can run without 
> most of src/engine.
>> * business => gnucash-business
> Currently, but a lot of the business logic will be needed in the CLI and that 
> is why I'm currently copying 99% of business-core/ into cashutil/src/ - 
> business-gnome and business-report remain GUI. Other files remain to be 
> identified.
> business-core/file will also need to live in the shared library if the current 
> GnuCash v2 XML backend is to be shared with the CLI.
> It may turn out that this isn't one but a set of libraries. I don't mind. What 
> I do want is an API that allows the user to interact with GnuCash data using 
> GnuCash objects via the CLI and all without the GUI being required. And 
> without impinging on any of the current GUI functionality - rather, I hope to 
> enhance it by providing a clearer API.
>> * {business,register,report}/gnome, gnome{,-utils} => gnucash-gnome
> Reports, utils, gnome - yes, gnucash GUI. There may be some UI logic in other 
> directories that can be abstracted but that's a way off yet.
>> * cashutil => cashutil
>>     [or maybe...]
>> * business/cli, register/cli, cli-utils => gnucash-cli  ??
> That's if CashUtil does come into the GnuCash tree. It's currently separate. 
> If this all turns out to be pie-in-the-sky then CashUtil can continue as a 
> separate project and I'll still be copying source files between trees.
> :-(
> Personally, I'd go for src/cli - containing only four source files: 
> qof-main.c|h which contain the generic QOF CLI interactive shell, init 
> functions and error messages that will also be found in PilotQOF etc., and 
> cashutil.c|h that contain the specific code to load the invoice, account, 
> customer etc. objects and ancillary logic from the financial logic library. 
> The usual manpage subdirectory would be beneath src/cli as well as a test/ 
> subdir.
>> > It's not straightforward and I won't have a definite answer on what goes
>> > where until the CLI is more advanced.
>> Hmm.  I guess you could look at the existing front-end and extrapolate
>> out what another would look like...
> I think some of pilot-link is a better example of the final CLI - I'm using a 
> lot of their menu and shell code. Unlike pilot-link, the CLI will be single 
> program, not a collection. With the vast majority of the code being QOF and 
> the shared financial logic library, CashUtil itself will likely be tiny 
> anyway.
>> > But business isn't separate in the real user world. It's a module but
>> > without recompiling gnucash, you can't *not* load it. The CLI needs the
>> > business objects and cannot work with the old gnc-module loading system
>> > so something does need to change.
>> The gnc-module loading system, I believe.  But that's a good point.
>> Things are structured so that is the case, though... maybe not fully,
>> but most of the way.  We should continue along that path, I think.
> Hang on, continue using gnc-module or continue moving to a non-Scheme library 
> approach? 
> IMHO, if we want to reduce the amount of Scheme in the engine and related 
> code, the business gnc-module needs to be overhauled. If the business object 
> files like gncInvoice.c remain in a Scheme loaded module, I'd rather keep 
> copying files around.
> :-(
> -- 
> Neil Williams
> =============
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at

       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL:    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list