Startup script changes: what and why

Wed Apr 7 03:21:54 EDT 2010

Dear Geert,

Just a quick heads-up from me about this change: I appreciate your  
changes very much! I think the previous implementation (shell script)  
was "the weird way" for an application to start, and your new  
implementation is "the normal way". After all, gnucash is just a  
normal application, and as such, it has a binary somewhere which  
contains a main() that should be called. Starting this in any other  
way instead of starting that binary makes the whole process  
significantly more error-prone, weird, and less accessible to all the  
developers, especially new ones. I appreciate any commit which gets us  
away from the "weird implementation way", more into the normal  
implementation way.

I have no problems with temporary breakage of the build on the  
platforms which you didn't test at first; that's just normal  
development. Different from some other responses here I think this is  
just fine and no, I don't think it is a requirement for any developer  
to test changes *on all platforms*. That's just the way of distributed  
and multi-platform development. Thank you again for working on this  
change!

Regards,

Christian

Zitat von Geert Janssens <janssens-geert at telenet.be>:

> 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
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>