On Wednesday 25 June 2014 18:38:39 Wm wrote:
> Tue, 17 Jun 2014 19:26:56 <13239941.bj5nrgt...@legolas.kobaltwit.lan>
> Geert Janssens <janssens-ge...@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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
