On Tue, 2005-07-19 at 17:25 +0100, Neil Williams wrote: > Whilst CashUtil is presently a separate tree, I have an eye on the changes > that would be required to fold it into GnuCash whilst retaining a separate > package, in effect making a gnucash-common package that would go alongside > QOF. The GUI would add the Gtk interface, the CLI could use the same two > libraries without any GUI dependency. CashUtil would be installable with or > without gnucash - for those SSH users.
"Without gnucash"? I think it should be... $ USE="cli" emerge gnucash # => ./configure --enable-cli ...not... $ emerge gnucash-common gnucash-gtk gnucash-cli (s/emerge/apt-get/ if you like...) If it's part of the tree, then it is, and we can optionally build it. What's the motivation for keeping it a seperate package? > We'd have the gnucash GUI frontend, libqof1, gnucash-common and the > gnucash-cli frontend - cashutil. CashUtil would depend on QOF and > gnucash-common. This would make CashUtil a v.v.small unit - not much more > than the shell and a manpage but by working out how to do this separately, it > will be easier to move the UI logic into common. Right now we have engine/ and app-utils/ and core-utils/ and calculation/ and ... 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. > 1. Lots of makefile changes to redistribute existing code - e.g. the business > objects are needed in the CLI without any gncmodule binding. Updating the > autotools would be a pre-requisite for that. Why would updated autotools be a pre-req for this? > gnucash-common would be a shared library that includes all the current > objects > - including the business ones - a QOF-enabled GncCommodity (got ideas on > that), Hmmm. It seems like we should preserve the ability to have optional modules -- like the business subsystem -- *not* need to be part of a core/common library. > Maybe something for GnuCash 2.2? > > A new branch? Maybe. The volume of change and the timing is probably sufficient to justify a 3.0, in which case this might be normal trunk development. I don't see, at this point, why it needs a branch. ...jsled -- http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
