Removal of ltmain.sh

[Neil Williams]

On Tuesday 19 July 2005 3:20 pm, David Hampton wrote:
> > By the way, we also have the file "acinclude.m4" in CVS. In current
> > automake/autoconf versions it is advised *against* that file, so at some
> > point in the future we should consider removing that file altogether.
>
> Agreed.  At some point (g2?) we should require current version of all
> the autotools, and clean up the code to work properly with them.

That would fit in with the API changes that were discussed in the CLI thread.

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.

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.

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.
2. Moving existing UI logic into another library, as discussed under the 
language bindings thread.
3. Remove scheme *entirely* from both of these areas - possibly by defining 
no-op hooks in the CLI where the GUI currently receives an event etc. Action 
would then depend on what is linked to the library - scheme or not.

This is how the CLI could work with the existing XML backend and SQLite when 
that arrives. What begins as a query CLI can be the CLI that people have 
desired for so long. 

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), and the presently ill-defined UI logic that is currently only in the 
GUI. As I move on with the CLI, I hope to identify precisely which bits of UI 
are actually necessary for a genuine CLI implementation of GnuCash, growing 
out of the current CashUtil.

Maybe something for GnuCash 2.2?

A new branch?

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050719/6ab1eadc/attachment.bin