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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
