dbus-launch in MacOSX build

[John Ralls]

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.

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? Yes again, the bundler can substitute a different environment file.

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.

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.

Regards,
John Ralls