[RFC Patch] Invert the program entry point

[Chris Shoemaker]

On Tue, Jan 03, 2006 at 11:07:07AM -0500, Derek Atkins wrote:
> Quoting Chris Shoemaker <c.shoemaker at cox.net>:
> 
> >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.
> 
> I, too, believe it's a good idea.  I've been suggesting this route
> as a quick-and-dirty way to get around the fragileness of /usr/bin/guile.
> Historically we've had a problem when /usr/bin/guile executes a version
> of guile different than the one gnucash was compiled against.  

Is that what motivated the libexec/overrides/* scripts?  Because I'm
not seeing why these things would still be needed after gnucash is an
executable.

> What you've
> done is effectively fixed that shortcoming..

I can't take credit for the design.  I've *never* seen a modular
program built like gnucash, but lots of programs do the
script-calls-executable-which-links-to-interpreted-modules-thing.

> 
> Over time we can move more of the initialization into C, but this is a
> good first start.  :)

Yes, it's intentionally a very small step, but I think it will make
that migration _very_ easy.

-chris