Removal of ltmain.sh

[Neil Williams]

On Thursday 21 July 2005 3:11 pm, Josh Sled wrote:
> > 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.

OK, I tend to consider the CLI as just CashUtil, then there's QOF (which I'd 
like GnuCash to use as a separate library by then) and if CashUtil is going 
to use all the logic inherent in the current GnuCash G2, as well as the 
current backend (+/- replacement), then the abstraction of the current UI 
logic into it's own API that is shared with CashUtil is going to mean that 
the GUI will be a front-end for the shared libraries behind it.

That is nowhere near where it is now, it's how I'd like it to be in the 
future. However, it is not a huge departure - GnuCash already uses a host of 
internal libraries. All I'm suggesting is a reorganisation of those libraries 
to put the financial logic alongside the objects in a library that can be 
used by the CLI. If that works, then the CLI can be folded into the GnuCash 
source tree.

The CLI and the gnucash-gtk front end would each be built against QOF and 
another library that contains:
1. All existing objects, business or otherwise.
2. Abstracted logic from what is currently the UI in a form that both programs 
can use.
3. The current gnucash xml v2 backend, including business object handling.

Each would have their own code to express:
1. Their own UI, Gtk for one, CLI for the other.
2. Suitable error message handling according to the UI, dialogs vs stderr.
3. The GUI would keep all the reports and tree model.

Once I've been able to demonstrate to myself that this could work, only then 
would I consider folding CashUtil into the GnuCash source tree - it would be 
natural then to share the new library that would be created by the fold as 
well as share the source code. Then I would finally be free from manually 
copying source files between projects!
:-)

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

The gnucash-common in Debian, as Thomas pointed out, is an architecture thing 
- not a UI/logic thing. It actually has nothing to do with the source tree 
and everything to do with i386 vs SPARC etc.

I thought of gnucash-common from a source perspective. It may not turn out 
that way. It may turn out to be a financial logic library, internal to 
GnuCash and CashUtil, with it's own API. 

> I just don't 
> conceptualize it that way, since the source isn't

It's a lot of work to reconfigure the source to allow this to happen. It's 
largely a case of removing all '#include's that reference private headers and 
replacing the calls with an API (leaving function either unchanged or 
enhanced) and switching files/functions around to make it easier to modify 
the Makefile rules to build the same code into differently structured 
libraries that better suit the logical divide between GUI and CLI.

Building the CLI as a separate project will allow me to identify those 
functions that are necessary for the proper logic in dealing with current 
GnuCash data in a CLI environment. Initially, the CLI will have limited 
financial logic and this is a weakness that is likely to confuse users and 
restrict the use of the CLI. Only by abstracting the logic from what are 
currently UI source files can I incorporate that logic into a CLI that can be 
built without a GUI environment.

> 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/]:

The gnucash engine IS QOF and vice versa. Each qof_ function is part of 
libqof1 and gnucash can run using QOF as an external shared library. There 
are no qof* functions outside QOF. Take a look at the source of QOF and 
you'll find all the files are common. When GnuCash eventually uses QOF as an 
external library, only the QOF objects (like Account and gncInvoice) need to 
remain in gnucash. CashUtil abstracts this further by putting those objects 
into a common library along with other ancillary logic sources that are 
currently spread over the entire tree.

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

No. Nearly everything src/engine/qof* and src/engine/gnc* is QOF. Gnucash can 
run quite well using the libqof1 library to provide these. In some ways, it 
already does as the engine code is built into an internal library. By making 
that internal library interchangeable with libqof1, gnucash can run without 
most of src/engine.

> * business => gnucash-business

Currently, but a lot of the business logic will be needed in the CLI and that 
is why I'm currently copying 99% of business-core/ into cashutil/src/ - 
business-gnome and business-report remain GUI. Other files remain to be 
identified.

business-core/file will also need to live in the shared library if the current 
GnuCash v2 XML backend is to be shared with the CLI.

It may turn out that this isn't one but a set of libraries. I don't mind. What 
I do want is an API that allows the user to interact with GnuCash data using 
GnuCash objects via the CLI and all without the GUI being required. And 
without impinging on any of the current GUI functionality - rather, I hope to 
enhance it by providing a clearer API.

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

Reports, utils, gnome - yes, gnucash GUI. There may be some UI logic in other 
directories that can be abstracted but that's a way off yet.

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

That's if CashUtil does come into the GnuCash tree. It's currently separate. 
If this all turns out to be pie-in-the-sky then CashUtil can continue as a 
separate project and I'll still be copying source files between trees.
:-(

Personally, I'd go for src/cli - containing only four source files: 
qof-main.c|h which contain the generic QOF CLI interactive shell, init 
functions and error messages that will also be found in PilotQOF etc., and 
cashutil.c|h that contain the specific code to load the invoice, account, 
customer etc. objects and ancillary logic from the financial logic library. 
The usual manpage subdirectory would be beneath src/cli as well as a test/ 
subdir.

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

I think some of pilot-link is a better example of the final CLI - I'm using a 
lot of their menu and shell code. Unlike pilot-link, the CLI will be single 
program, not a collection. With the vast majority of the code being QOF and 
the shared financial logic library, CashUtil itself will likely be tiny 
anyway.

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

Hang on, continue using gnc-module or continue moving to a non-Scheme library 
approach? 

IMHO, if we want to reduce the amount of Scheme in the engine and related 
code, the business gnc-module needs to be overhauled. If the business object 
files like gncInvoice.c remain in a Scheme loaded module, I'd rather keep 
copying files around.
:-(

-- 

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/20050721/42a597ca/attachment.bin