dbus-launch in MacOSX build

[Geert Janssens]

On Monday 5 April 2010, John Ralls wrote:
> On Apr 5, 2010, at 10:56 AM, Geert Janssens wrote:
> > The current svn head should still handle the run-from-original-build-
> > environment fine. The launcher may need a little tweaking.
> > Basically, whatever environment variable that was set via
> > gnucash-setup-env is now defined in the environment config file. Gnucash
> > will read this file at early startup. So as things are now, the
> > environment is setup twice when using the launcher script, and the ones
> > coming from the environment file will take precedence. So if the paths in
> > the environment file still happen to exist, objects will be fetched there
> > first which could cause all kinds of funky results.
> >
> > **Pondering** The nicest thing would be if the launcher script could use
> > the environment file as well. Many of the environment variables are
> > required in both situations, but they use different values. I suppose the
> > tricky part is that the paths setup in the launcher script are relative
> > to the bundle, while the environment file uses absolute paths.
> >
> > The environment config file is stored in ${prefix}/etc/gnucash at install
> > time, so I suppose it will end up in $bundle_etc/gnucash when GnuCash is
> > bundled.
> > Are you allowed to write to files in the bundle from your launcher script
> > ? If so, you could rewrite the environment file to your likings from
> > within the launcher. Perhaps that's not done, I'm not familiar enough
> > with Quartz.
> 
> The svn head as of a couple of hours ago doesn't run from the command line;
>  it appears that dbus doesn't start. I was building a bundle, but I guess I
>  needn't do that if you've overridden the environment.
> 
Do you mean an unmodified gnucash script doesn't run ? This shell script 
should still call dbus-launcher as before.

> I've just started again in the unlikely event that r18996 changes
>  something.
> 
> Yes, the bundle's launcher script can source the environment config file,
>  but if the binary is going to read it again, what's the point?
I didn't mean for the launcher script to source the environment file, I meant 
to setup a proper environment file and don't bother setting the same 
parameters again in your launcher script. But I realize this is a silly 
duplication of effort.
>  Yes again,
>  the bundler can substitute a different environment file.
> 
Then your most easy way out for the bundle is to subsitute the environment 
file with a file containing only:
[Variables]

This way the environment file will effectively do nothing.

> Your logic is inverted, though. Gnucash should absolutely, positively NOT
>  override the user's environment. That's unbelievably rude -- and it has
>  nothing at all to do with OSX.
> 
I'm not overriding anything other than what was being overridden already. 
Perhaps appending might be a better word. The environment changes are only 
local to GnuCash. It's not GnuCash itself that requires this. It's the guile 
interpreter forked by GnuCash that needs to find the GnuCash provides scheme 
files. As far as I can tell that's the only reason GnuCash messes with the 
environment and always has.

> What is the point of this exercise, anyway? Surely there are better uses of
>  your time -- and I know that there are better uses of mine.
> 
The point is easier debugging -- lowering the barriers for new developers. The 
current start script is an unnecessary hurdle to take. You can't just start 
gdb gnucash, because gnucash is a shell script. Most IDE's can't easily run 
their debugger on the code, because there's a shell script in between.

Clearly in the case of a bundle it doesn't matter. The bundle's launcher 
script is a shell script in itself.

It's not my intention to waste your time. I'll do the debugging for Mac OSX as 
well, if you can just provide me with enough information to do so.
What's the contents of the gnucash script ? Any messages on the command line ?

Geert