Startup script changes: what and why

[Geert Janssens]

I have recently committed a number of changes to the startup scripts. I seem 
to have involuntarily caused some commotion among the devs by doing so. I 
thought it might be best if I wrote down exactly what I changed and why.

Let's start at the beginning. GnuCash is a binary program (gnucash-bin), 
developed in C. It embeds a guile interpreter for easy scriptable extensions 
like reports. When I started developing for GnuCash I was confused as to why 
this binary program couldn't start directly, but instead relied on a wrapper 
script to start it.

This wrapper script alters the environment before gnucash-bin itself is 
started. It took me a while to understand this was because of the embedded 
guile interpreter: the guile interpreter reads some environment variables to 
find the gnucash-specific guile add-ons.

So in other words the wrapper script "configures" the embedded guile 
interpreter. For me this sounded weird. A binary program is not normally 
configured with a shell script. I remember that older versions of GnuCash 
started as guile script, which eventually called a C-main function. This was 
before I started developing on GnuCash. I imagine this script/main program 
combination just naturally continued.

This in itself didn't bother me too much and I let it be for a long time. 
Since november last year, I have started to commit more seriously to gnucash 
development. I have been monitoring bugs, trying to fix what I could, 
debugging on the go,... And there I got frustrated. It seems that contrary to 
most other devs, I'm prefer GUI to do my development (Eclipse if you wish to 
know). The fact that GnuCash has to be started via a shell script effectively 
prevents me from using the Eclipse integrated debugging environment in a 
convenient way. I have worked around it for a while with gnucash-ddd or 
attaching to a running process, but both turned out suboptimal in many cases.

So it finally got me thinking about that shell script and why it is there in 
the first place. It is there to help the embedded guile interpreter find the 
gnucash provided guile add-ons. Surely this doesn't really need a shell script 
? Most programs I know use a configuration file for configuration. So I set 
out to achieve just that: change GnuCash in such a way that it reads a 
configuration file and uses this to configure the guile embedded interpreter 
appropriately.

What does it do exactly ?

This configuration file is a simple INI-style text file, much like the book 
state files already in use by GC. GnuCash reads this file at startup, and uses 
it to modify the environment, exactly as the start scripts did before.

The contents of this file is created by the build environment (currently only 
the autotools on linux). The build environment can set whatever parameters 
required for GnuCash to run properly, which is ensure that embedded guile 
finds the necessary gnucash guile add-ons.

Note: I simplified the explanation a little bit: there's also a parameter set 
for DBD. But this doesn't change the concept or implementation. The config 
file can be used to set some environment parameters to be used by things 
embedded in gnucash and only that.

So, as to the big question why ? Because my frustration with gnucash risked 
getting too high. I want to help out and improve GnuCash. But I will only do 
that if I continue to enjoy it. That's mostly why. And while I was working on 
it, I figured that I may not be the only potential contributor that prefers a 
GUI development/debug environment.

As a secondary question: why now ? GnuCash 2.4 will be released in a 
relatively short time frame. This stable branch will be maintained for quite 
some time. And I say "maintained", which means mostly bugfixing. This entails 
debugging. I intend to help in this maintenance, but I didn't look forward to 
the unpleasant debugging experience I had until now. Suppose I did these 
changes only after 2.4 was branched. I don't think this change would be a good 
candidate for backporting to the stable branch. This would mean I would have 
to go on debugging in the same inconvenient situation I am in now, which 
frustrates me now already. For the record: I'm not implying gdb and command 
line development are "not good" in any way. I try to be clear about it that 
I'm not sufficiently familiar with it to use it fluently.

Now, I do admit I made some mistakes in the process.

Firstly, I never realized that the OSX/Quartz build had a separate launcher 
script for the osx bundle. So my first attempt (which I did test thoroughly on 
linux) effectively ruined John's day (sorry John).

Next, I did notice that the ox build ran additional commands in the startup 
script. I messed up trying to keep those commands while rewriting the script. 
This also hit the osx/quartz build.

These two lead to mistake number 3: I should not have committed anything 
before I had a chance to test the impact on all platforms. I have run tests on 
linux and on Windows, but not on OSX.

I am responsible for these mistakes, and I'll spend the time required to 
correct all of them. In the process I have learned a lot about the specifics 
of the different platforms that I would have learned only very slowly by 
reading code.

Another question no doubt others would ask: is all this trouble worth it if 
the next development cycle will move to another gui toolkit ? I don't know in 
general. The discussion on a different gui toolkit hasn't truly started yet, 
so maybe my code changes will disappear completely in GnuCash 2.5. The guile 
interpreter will likely stay though, so it would still make sense to have some 
code to configure it. But for ME, this is worth it for the reason I stated 
above: I want to continue to work on GnuCash in a way I enjoy. This code 
change will help me with that.

Geert