Removal of ltmain.sh
linux at codehelp.co.uk
Wed Jul 20 15:41:03 EDT 2005
On Wednesday 20 July 2005 6:19 pm, Josh Sled wrote:
> 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"?
Yes. For those situations where you want to be able to access the data file
without a GUI environment being available. It's far easier to scp a 2Mb data
file than to live with X over a slow network connection.
I certainly want to be able to install cashutil on non-GUI systems. Also on
non-X systems and remote X systems.
> I think it should be...
> $ USE="cli" emerge gnucash # => ./configure --enable-cli
?? I don't know emerge but that won't work with apt-get.
> $ emerge gnucash-common gnucash-gtk gnucash-cli
> (s/emerge/apt-get/ if you like...)
But it would be:
# apt-get install gnucash cashutil
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.
Users would only install whichever they needed.
> 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?
Project: separate source tree, separate CVS, separate support.
Package: decision by distribution maintainers on how to make their
1. It is a separate project currently because it cannot yet deal with the
2. Even if it is part of the gnucash CVS tree (which it would be if it does
get to deal with the current backend), it can still be a separate package at
the user end (apt-get).
> > 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 ...
You're looking at the source tree, I'm looking at the apt-get package list.
> 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.
It's not straightforward and I won't have a definite answer on what goes where
until the CLI is more advanced.
But, as Derek pointed out, this is all maintainer stuff. I'll be discussing it
off-list with the Debian maintainer (as gnucash-common DOES already exist).
None of this needs concern the source tree, only the Makefiles. There might be
a few files moving directory but that's already being done in G2.
Let me get the CLI working and then I'll come back with a definite idea of
what needs to go where.
> > 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?
Because it'll make it easier to reorganise the current library make
instructions so that object source files currently in the business module
(for example) can be directed into an existing library making that suitable
for linking against the CLI.
e.g. I need Account.c and gncInvoice.c in the same shared library (or at least
loadable in two libraries that do not rely on any scheme). Those would be
packaged at the user end as part of gnucash-common.
Currently, I'm working with copies from the current tree.
> > 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.
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.
I'm OK either way - if I copy the objects into a new tree then I'll have the
same situation as now with QOF, with the advantage that the object files
change less frequently!
-------------- 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/20050720/3be81b31/attachment.bin
More information about the gnucash-devel