Building on Windows from scratch, enable-python and some vs suggestions

Wm Tarr wm.tarr at
Thu May 15 18:16:02 EDT 2014

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 
* 21:34:24  INFO <gnc.gui> [main] Effective locale set to English_United 
* 21:34:32  INFO <gnc.engine> [gnc_hook_lookup] no hook lists
that is all of it

I've added
to my 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
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... 
checking for /c/Python27/python extension module directory... 
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

this wouldn't affect nix installs as my conceptual gnc-disutils in 
python would be returning values sensible to gnc's configure


More information about the gnucash-devel mailing list