dbus-launch in MacOSX build

[John Ralls]

On Apr 5, 2010, at 11:47 AM, Geert Janssens wrote:

> 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 ?

r18994 didn't insert the PRE-RUN because you had set platform=osx after the Gdk_quartz test, but tested for platform=darwin. You fixed that in r18996. (It occurs to me that MacPorts also builds a quartz version, so they still might have trouble with this. Dave Reiser will have to comment on that.

As it happens, the bundle runs just fine without modification, so from that standpoint all is well. It's probably because of the linking hack in the launcher script.

I see now what you're doing with the environment variables. OK, I guess. I understand about debugging, but gdb attach works well, and I'm pretty sure that gdb is what's under the hood of all of the useful IDEs since gnucash requires MinGW/MSys on MSWin and won't therefore be getting debugged in Visual Studio.

Regards,
John Ralls