Future of cashutil. (was Re: Radically improve autogen.sh)

[Neil Williams]

On Monday 07 November 2005 12:56 am, Derek Atkins wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
> > My only problem with that on Debian is this build-within-a-build in
> > cashutil branch. I need to be able to hook cashutil/configure onto the
> > end of ./configure in a wrapper script that passes on the --prefix and
> > nothing else.
>
> You shouldn't use a build-within-a-build.  You should integrate
> the cashutil dirs into the main configure script.

But then I can't have a separate po directory. How can gnucash and cashutil be 
packaged separately if they use the same translation files? I also use a 
different manpage system, have vastly reduced numbers of dependencies and 
currently retain the ability to package cashutil as a separate tarball with 
it's own ./configure. Documentation should also be separate, hence 
[branch]/cashutil/doc/doxygen.cfg.in as well as 
[branch]src/doc/doxygen.cfg.in amongst other differences.

Currently, the build creates cashutil.mo and gnucash.mo - one ten times 
smaller than the other. This is ideal because it allows me to package 
cashutil separately so that it can be installed without gnucash.

> -derek

Christian wrote:
> In the long run I agree with Derek: If the command line tool "cashutil" 
> is supposed to be distributed together with gnucash

No, it's not - it can be but it is not essential. It shares some of the 
codebase but is designed explicitly to be installable without gnucash (or Gtk 
or any GUI component). It has a much shorter dependency list and that's how I 
want it to stay.

It does currently go into the gnucash make dist tarball but it doesn't have 
to. If the shared codebase can be made available, cashutil can still be a 
completely separate project.

Users should have the choice to install cashutil only, gnucash only or both. 
If installing only cashutil, there must be NO GUI dependencies of any kind 
and definitely no guile.

CashUtil, like QOF, is going onto platforms that cannot support gnucash or 
even Gtk.

> (which is implied by  
> the fact that it's in the same CVS^H^H^H SVN module),

I disagree. It's in the same SVN repository because it shares the QOF objects 
and the gnc-backend-file sections of the codebase. That is the only reason.

> then it should be  
> built by the very same top-level ./configure.

It can be, providing the cashutil/configure is chained on!
:-)

> No need for an extra  
> build-within-a-build.

Well, the alternative is that gnucash explicitly packages libcashobjects, 
libcashbusobjects, libgnc-backend-bus and libgnc-backend-file (preferably as 
one shared package). (See the current cashutil branch for what goes into 
those libraries). At a later date, gnucash would share a logic library that I 
would create within cashutil and package into the one shared package. Then 
I'll simply link cashutil against the objects and load the backend as a 
GModule. I'd move cashutil over to SourceForge and remove the cashutil 
branch.

I want to have the option to extend cashutil in the future into an embedded 
application using the same objects (probably not using gnc-backend-file 
though). I want cashutil to be installable on systems that could never dream 
of installing gnucash. It's about data accessibility, data freedom, 
portability and maximum platform support.

I can't see how this can be done if cashutil is absorbed into the 
gnucash ./configure - if there is a way, I'm happy to use it but I won't 
sacrifice the ability to install cashutil on a system with no Gtk, gconf, 
guile or bonobo. GnuCash is too big, too complex and there is a clear need 
for a simpler, faster interface that does not demand anything like the 
requirements of a gnucash install. That's why there are apps like FreeCoins, 
PCash and brinance.

Cashutil started as a simple QOF example with gnucash objects. That simplicity 
is it's main strength and it should not be seen as a "component of gnucash" 
but as a separate utility that shares gnucash code. I'm building cashutil to 
have a generic user interface - an embedded UI could be bolted on as easily 
as the CLI.

-- 

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/20051107/2232f725/attachment-0001.bin