Removal of ltmain.sh

[Josh Sled]

On Wed, 2005-07-20 at 20:41 +0100, Neil Williams wrote:
> 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.

Oh.  "Without the gnucash gtk-gui".


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

Okay.  I understand apt-get does this via multiple packages rather than
attributes (gentoo: "use-flags") on a single package.


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

gnucash != gnucash-gnome-frontend.

I guess that's the misunderstanding... you keep calling the
gnome-frontend "gnucash" and all the non-gui-related stuff
"gnucash-common", as the debian packages are that way.  I just don't
conceptualize it that way, since the source isn't and I don't use
debian.


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

Maybe mis-reading you, but I don't see how the gnucash engine concepts
go into the QOF package...?  I see [all in src/]:

* {engine,{app,core}-utils,register/core,reports/core,...} => gnucash

* business => gnucash-business

* {business,register,report}/gnome, gnome{,-utils} => gnucash-gnome

* cashutil => cashutil
    [or maybe...]
* business/cli, register/cli, cli-utils => gnucash-cli  ??


> It's not straightforward and I won't have a definite answer on what goes where 
> until the CLI is more advanced.

Hmm.  I guess you could look at the existing front-end and extrapolate
out what another would look like...


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

The gnc-module loading system, I believe.  But that's a good point.
Things are structured so that is the case, though... maybe not fully,
but most of the way.  We should continue along that path, I think.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`