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

Wm Tarr wm.tarr at
Fri May 9 11:51:06 EDT 2014

I'm working my way through getting python enabled with "Windows from 

Before anyone gets too excited it is early days but building on Geert's 
work makes a lot more sense than previous methods to me.

Unless I've missed something we're going to need a way of passing 
--enable-python and possibly some LDFLAGS to configure in

       function inst_gnucash() {
         $_REPOS_UDIR/configure ${HOST_XCOMPILE} \

configure understands the python stuff but there isn't a way of telling 
it you want it without hacking at the moment which I 
think is against the ethos of what we're achieving with "Windows from 

I'd have thought a variable that could be set in that was 
understood by configure in install-impl.shwould be a better way of 
approaching this.

CONFIGURE_FEATURES=""                 # as a default, perhaps?
CONFIGURE_FEATURES="--enable-python" # in this example.

I'll leave the name of the variable to Geert and others more fimiliar 
with the scripts than myself but my suggestion is based on configure 
having --enable-python under Optional Features.

On a similar note my install.log says
configure: WARNING: unrecognized options: --enable-schemas-install, 

neither of these are causing problems that I've noticed but the hard coded
seems to be a sensible option to remove from install-impl.shas configure 
doesn't know about it and move to CONFIGURE_FEATURES or similar in and friends.

similarly --with-ofx-prefix which is set along with some other stuff in 
     LIBOFX_OPTIONS="--enable-ofx --with-ofx-prefix=${_LIBOFX_UDIR}"
shouldn't all of these be in and friends rather than hard set?

Maybe I've misunderstood but I thought the idea was to make the number 
of files a user should be expected to fiddle with as few as possible.  I 
think I'm adding to that with my suggestion.


Further, my idea is to end up with a set of instructions that go 
something like
do "Windows from scratch"
do python
make a copy of
copy to
adjust if necessary as per existing instructions
see if it works

The bit below is homework for me so if you (anyone) can help or see 
anything obvious, good, otherwise I'll continue to hack away.

Details: I'm not sure if I'm doing something wrong regarding the 
LDFLAGS, it looks like they shouldn't be needed but this is the moan I get:
checking for a Python interpreter with version >= 2.4... python
checking for python... /c/Python27/python
checking for python version... 2.7
checking for python platform... win32
checking for python script directory... ${prefix}\Lib\site-packages
checking for python extension module directory... 
checking for python2.7... (cached) /c/Python27/python
checking for a version of Python >= '2.1.0'... yes
checking for a version of Python >= '2.4'... yes
checking for the distutils Python package... yes
checking for Python include path... -Ic:\Python27\include
checking for Python library path... -Lc:\Python27\Lib\config -lpython27
checking for Python site-packages path... c:\Python27\Lib\site-packages
checking python extra libraries... None
checking python extra linking flags... None
checking consistency of all components of python development 
environment... no
configure: error: in `/c/gcdev/gnucash/build':
configure: error:
   Could not link test program to Python. Maybe the main Python library 
has been
   installed in some non-standard library path. If so, pass it to configure,
   via the LDFLAGS environment variable.
   Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib"
    You probably have to install the development version of the Python 
    for your distribution.  The exact name of this package varies among 

See `config.log' for more details

something similar was experienced by Rayalan as described on

at the moment my thoughts are:

why am I getting ${prefix} and ${exec_prefix} rather than the paths that 
were given?
why do the include path, library path and site-packages path switch to 
DOS notation (c:\) when they've been provide as /c/ in env?

all part of the merry-go-round, eh?


More information about the gnucash-devel mailing list