Removal of ltmain.sh
linux at codehelp.co.uk
Tue Jul 19 12:25:43 EDT 2005
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050719/6ab1eadc/attachment.bin
More information about the gnucash-devel