Removal of ltmain.sh

[Josh Sled]

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 ${a}@${b}`