[RFC Patch] Invert the program entry point

[Chris Shoemaker]

On Tue, Jan 03, 2006 at 08:06:00AM +0000, Neil Williams wrote:
> On Tuesday 03 January 2006 6:18 am, Chris Shoemaker wrote:
> > Folks,
> >         I'm interested in comments on the attached patch.
> 
> I too have been working on a gnucash C executable - but with even less links 
> into guile. I could get it to load gnucash as far as the splash screen, load 
> all the modules but had problems at the main window stage. (Hence it hasn't 
> been committed.) I think the problems are just down to some additional 
> configure defines that have unwanted side effects.
> 
> I'm certainly in favour of working with you on this process.

I'm glad there seems to be a consensus that this is a good idea. 

> 
> My test routine is for the cashutil branch and creates gnucash2 - a typical 
> binary executable from C source. I added some of the cashutil popt calls so 
> that, in effect, gnucash2 implements a lot of the cashutil CLI.

That confuses that matter somewhat.  Not just the code, but also
conceptually: what is the relation between the gnucash executable and
the cashutil CLI?

> 
> (cashutil itself would retain the --shell interface that provides all the add, 
> edit, delete, undo, redo support as well as implementing the gnucash2 CLI for 
> users who don't have the --gui installed.)

That raises another question: What is the intention for the cashutil
branch?  Is it meant to eventually be merged into trunk?  Or is it
just a place to develop cashutil while making it convenient to update
the parts that cashutil and gnucash share?  

As I understand it, cashutil is meant to be a stand-alone app, not
depending on gnucash - basically a CLI for qof.  But does it
accomplish that?  And if so, is it by linking to gnucash libraries
that don't yet exist in trunk?  (e.g. libgnc-bus-backend?)

> 
> I'll commit to the cashutil branch later - my error is probably obvious to 
> others so please, don't be too critical of it! (I know it doesn't work 
> properly.)
> 
> :-)

I think everybody knows how I feel about the virtues of sharing even
broken code.

> 
> Unfortunately, it's not a small commit because I've had to merge a lot of 
> trunk changes into the cashutil branch (e.g. merging the lib/libqof changes).

Unfortunately, that's not why it's not a small commit.  Anyway, merge
commits should be separate from "change" commits.  But, the commit is
big because most of it is unrelated to building a gnucash executable.  

That's what really raises the question about intention.  There are
pieces of the commit that I'd be uncomfortable with in gnucash.  But
if they're not meant for gnucash, it doesn't matter.

OTOH, some of the commit looks to be along the lines I was planning on
heading: moving stuff from main.scm into C.  It would have been more
helpful if that stuff were isolated from all the cashutil-specific
stuff.  Basically, it's the difference between me seeing your code as
an example of how a very similarly-built application made the
transformation, and me seeing your code as implementing that
transformation for gnucash.

> 
> One comment on gnucash2 - as a 'standard' popt interface, I've currently 
> implemented it so that if no commands are given, gnucash2 prints --usage and 
> exits. I've done this because gnucash2 has lots of other CLI commands and 
> options:
> 
> bin$ ./gnucash2
> Usage: lt-gnucash2 [-g|--gui] [--no-file] [-?|--help] [--usage] [-l|--list]
>         [--explain] [-x|--xml-file filename] [-t|--date string]
>         [-d|--database string] [-e|--exclude string] [-s|--sql string]
>         [-f|--sql-file filename] [-w|--write filename] [--compress=integer]
>         [--debug] [--version] [-c|--category string]
> 
>    GnuCash: Open Source Accounting Software
>    See http://www.gnucash.org/
>    Use --help for more detailed help or
>    -g to load the gnucash main window.
>    Use exactly one of -x -l -g --explain;
>    options are -c -t -w, -d or -e, -s or -f.
> 
> To load the gui, I've got a specific command:
> $ gnucash2 --gui
> or using short popt syntax:
> $ gnucash2 -g
> 
> Is this a no-go ? I think it would be fine to specify --gui for the desktop 
> icons etc. 

In theory, I don't think it's a big deal, IF your executable depends
on pre-execution environment prep.  It looks like you attemt to do all
the environment prep _during_ execution, which IMO, makes it more
important to support the no argument case.

> 
> gnucash2 would allow arbitrary SQL-type queries to be run against gnucash data 
> on the command line, allow users to list the supported objects and see an 
> explanation of all their parameters. category is a red-herring - it's 
> inherited from the Palm work that lies behind the gnucash2 popt CLI. 
> 
> gnucash2 sql-type queries result in QSF being output, either to stdout or to a 
> file using --write.

IMO, this doesn't belong in the gnucash executable.  It sounds like
cashutil.  If we want the gnucash executable to support stuff like
this one day, we should link with the libcashutil, right?

> >         This design has several disadvantages that I don't want to get
> > into right now, but several of them can be avoided by a small change
> > in the attached patch.  Basically, we can just provide a main()
> > function in C, link to libguile, and build an executable that calls a
> > guile module.  That's what this patch does.  It installs an alternate
> > startup script 'gnucash-test' in the bin directory which calls the
> > 'gnucash-bin' executable, which starts up Gnucash.  Tada! Gnucash is
> > now a C program that happens to link to some libraries written in
> > guile.
> 
> I can add CLI code to this C source to completely replace command-line.scm - 
> as long as loading the main window can be sorted out.

Do you just mean argument-handling code?  If so, how hard would it be
to provide code that applies to trunk, without the cashutil stuff, and
without actually changing the arguments handled?

> 
> >         BTW, I think that one consequence of this change would be that
> > it would become much easier to move the entire start-up sequence from
> > guile to C.
> 
> I've got 75% of that startup sequence in gnucash2.

I think you just took too big a step at once.  My approach is to keep
it always 100% working, but just make small steps to move it from
guile to C.

> 
> >         WorksForMe(tm) but I'm especially interested to hear if I've
> > missed anything.  I've delayed committing on the chance that there's
> > some fundamental flaw in this design.  So speak up if so!
> 
> I'll commit to the cashutil branch, you can take a look at gnucash2 and we can 
> work together - that may be the best solution.

Unless you want to break out pieces that can apply to trunk, I can use
the cashutil branch as an example, and see how much I can copy.

You seem confortable with popt.  Do you want to convert the argument
handling into C?

-chris