On 14/05/2014 00:42, Wm Tarr wrote:
[ff to self]
1. there is a conflict between gcdev\gnucash\build\config.h and
Python27\include\pyconfig.h
2. More seriously (and I think recently introduced) is a duplicate
variable (I didn't make a note of the error msg) between
Those are still outstanding. I don't think 1. is a real problem either
way and 2. If I understand correctly, is a test that once passed
shouldn't affect the actual code that makes the gnucash executable
If I am right about that we can pass by and continue to where I need help.
More generally the
checking for /c/Python27/python script directory...
${prefix}\Lib\site-packages
checking for /c/Python27/python extension module directory...
${exec_prefix}\Lib\site-packages
just aren't working out on Win.
I'll see how I feel tomorrow but the way I'm looking at it right now I
think I'm going to sed the Makefile after configure in function
inst_gnucash() because the results *really* are that ugly and MSYS
(unlike cygwin) can't seem to sanitise the paths reliably and I've
spent much too long on this unimportant issue.
I've fixed those. Two lines added to configure to overcome paths that
have mixed forward and back path separators. As I think Geert alluded
to earlier MSYS can accommodate all forward or all back but doesn't deal
well with the mixture. I think my change will fit in with the generic
or system independent configure in that I go for all forward but it
isn't a big deal to implement it now, that is for tidying up and
normalising later.
My compile with enable-python is clean but the resulting .exe doesn't
work, or rather, it doesn't work for long.
trace logs are like this
===
* 21:34:24 INFO <gnc.gui> [main] System locale returned English_United
Kingdom.1252
* 21:34:24 INFO <gnc.gui> [main] Effective locale set to English_United
Kingdom.1252.
* 21:34:32 INFO <gnc.engine> [gnc_hook_lookup] no hook lists
===
that is all of it
I've added
===
export DISABLE_OPTIMIZATIONS=yes
===
to my custom.sh in an effort to get more stuff from
===
start gnucash --debug --extra
===
but that is it, so far.
I've also added just about everything that seems likely to the PATH
before gnucash is run in case it needs something extra but it hasn't
made any difference [1].
The most recent account of a trace ending like that I found
===
http://gnucash.1415818.n4.nabble.com/Fresh-install-of-gnucash-2-5-6-crashes-on-windows-td4664635.html
===
seemed to be related to dirs existing but I'm not sure that is related
as if I build + run without enable-python it is fine and with it isn't.
This is repeatable regardless (my build times are around an hour 20 per
significant change at the moment, not quick if you have super kit by
comparison but around the right sort of time to kick off and read for a
bit, I also rename my .exe files so I can run std or py in any env).
It has made me wonder if my env isn't right in spite of [1] above. Any
suggestions / hints? If you have a working nix or win env I'd be
interested in seeing it as it is possible I've missed something, I talk
both OSs so if yours is nix don' be shy, I'll translate.
On to the python+gnc bit, in spite of my gnucash.exe not getting far my
python seems to be doing quite well, except I'm not sure
===
checking for /c/Python27/python script directory...
${prefix}/Lib/site-packages
checking for /c/Python27/python extension module directory...
${exec_prefix}/Lib/site-packages
===
are right. I know the paths are right and work because I had to play
with configure but I'm not convinced configure is getting the right
paths from python. What are your prefix and exec_prefix ?
It has been mentioned that the extant py scripts may be out of date.
I'd appreciate it if anyone knows a recently working test script, where
you have it in your hierarchy, what your env is, etc. I can translate
between *nix and Win fine so solutions from either / any camp are welcome.
The script could be as short as "python ; import gnucash" ; I'm asking
for something that is known to work based on env
============
Longer term I think it worth discussing whether enable-python on gnc
should not perhaps have its own python distutils import. Certainly many
of the problems I've come across could have been solved by a consistent
interface between (gnc)configure and python.
My idea (modifed as and when) is:
you get gnc working
you grab a python
you add gnc-distutils (or similar)
configure tests for gnc-distutils and if exists gets reliable paths
continue
this wouldn't affect nix installs as my conceptual gnc-disutils in
python would be returning values sensible to gnc's configure
--
Wm
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
