Fix for installation of HTML Help Workshop on Windows Vista & more recent

[Geert Janssens]

On Wednesday 25 June 2014 18:38:39 Wm wrote:
> Tue, 17 Jun 2014 19:26:56 <13239941.Bj5nrGT431 at legolas.kobaltwit.lan>
> Geert Janssens <janssens-geert at telenet.be>
> 
> [quote reordered]
> 
> >On Tuesday 17 June 2014 18:05:28 Geert Janssens wrote:
> >> I have just pushed a number of commits to gnucash-on-windows that
> >> hopefully fixes the issue that HTML Help Workshop could not be
> >> installed on Windows Vista and more recent due to insufficient
> >> privileges.
> >> 
> >> I don't have such a Windows system so I need some volunteers to
> >> test
> >> it and give feedback.
> >> 
> >> The way to test would be to set up a development environment on
> >> Windows following the instructions here:
> >> https://github.com/Gnucash/gnucash-on-windows/blob/master/README
> >> 
> >> If you already have a development environment set up based on the
> >> gnucash-on-windows repository you can skip the basic set up and
> >> just
> >> remove HTML Help Workshop via the Windows control panel and rerun
> >> install.sh
> >> 
> >> What I hope is that you can successfully install HTML Help Workshop
> >> when during the corresponding step. On Windows Vista and more
> >> recent
> >> I expect Windows to show a UAC which you should grant.
> >> 
> >> In all cases, please keep in mind that you should *NOT* install
> >> HTML
> >> Help Workshop in the gcdev directories. Just install it in the
> >> default location somewhere under Program Files or similar. This has
> >> the added benefit that one single installation is ever needed. If
> >> you
> >> set up multiple development environments for gnucash, they will all
> >> use the same HH installation.
> >> 
> >> I'm looking forward for all feedback.
> >
> >I just found a bug in my own code: if you install HTML Help Workshop
> >in a path containing
> >spaces the gnucash build step will fail. I'm looking into this right
> >now. The htmlhelp step
> >itself should work though.
> 
> I haven't checked what else has changed [1] (obviously boost is new)
> but ===
> \gcdev\gnucash-on-windows.git\install-impl.sh
> line 1419
> is breaking the build as the PATH to hhc isn't being remembered from
> (I think)
> ===
> function inst_hh ()
> 1146    _HH_UDIR=`unix_path $HH_DIR`
> 1147    _HH_SYS_UDIR="`unix_path $HH_SYS_DIR`"
> ===
> 
> 
> so
> ===
> function make_chm()
> 1418        echo "Will now call hhc.exe for $_CHM_TYPE
> ($_CHM_LANG)..." 1419        hhc htmlhelp.hhp  >/dev/null  || true
> 1420        echo "... hhc.exe completed successfully."
> ===
> can't find hhc.   if I change line 1419 to
> ===
>          /c/e/progs/hh/hhc htmlhelp.hhp  >/dev/null  || true
> ===
> where: /c/e/progs/hh/ is my new HH location with no spaces it builds
> OK so finding hhc in the PATH is the issue.  I'm guessing that when
> you moved HH out of the build directory the PATH to hhc.exe was in
> your environment so you didn't notice the HH DIR related changes in
> inst_hh()
> 
Thanks for the heads up.

I'm not sure why I didn't notice this. There is no hhc anywhere on the path at this point. There 
may have been one before, I don't recall.

In any case I'm testing a fix now. It's a one-line fix. You may want to test it already as well 
before I push it:
In install-imple.sh, change line 1161
from
    add_to_env $_HH_UDIR PATH
to
    add_to_env $_HH_SYS_UDIR PATH


> 
> [1] I had [2] given up on your build + python and moved my attention
> to building under cygwin and understanding how applications like GIMP
> that need python and work on Win just as well as *nix manage what we
> (or at least I) seem unable to do.
> 
> [2] language note: "had" past tense.  I'll have another go but the
> whole gnc + python (not just on Win) all seems very flaky. [3]
> 
> [3] This is probably better suited for another thread but there are
> some parts of configure that I don't believe could ever have resulted
> in a working gnc+python under Win.  Maybe a working gnc+python has
> never actually happened and is actually mythical?  I thought I'd be
> formalising something extant ...
I don't recall offhand where you started and what your goal is.

I have successfully used the python bindings to synchronize data between an inhouse inventory 
system (based on postgresql and - yuck - MS Access 2000). This relied on querying several 
business objects, accounts, transactions, lots and splits. So that part did work well at least in 
the 2.4 series. I haven't ported my scripts to 2.6 because we switched to a different system 
around the same time.

So I would indeed think you were formalising something existent. But from what I've read and 
heard it's pretty ugly to get python on Windows to cooperate with mingw based applications. I 
have never tried that because I'm on linux 99% of my time. I tried to follow your progress but I 
don't have enough spare time lately :( So it's still in my queue somewhere.

I'll let you know when I get to it.

Geert