Removal of ltmain.sh

Neil Williams 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.

> ...not...
>    $ 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?

Confusion here.

Project: separate source tree, separate CVS, separate support.
Package: decision by distribution maintainers on how to make their 
dependencies work.

1. It is a separate project currently because it cannot yet deal with the 
current backend.

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!

-- 

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/20050720/3be81b31/attachment.bin


More information about the gnucash-devel mailing list