Building on Windows from scratch, enable-python and some install-impl.sh vs custom.sh suggestions

[Wm Tarr]

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

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

   gnucash-on-windows.git
     install-impl.sh
       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 install-impl.sh at the moment which I 
think is against the ethos of what we're achieving with "Windows from 
scratch".

I'd have thought a variable that could be set in custom.sh 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, 
--with-ofx-prefix
===

neither of these are causing problems that I've noticed but the hard coded
===
     --enable-schemas-install=no
===
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 
custom.sh and friends.

similarly --with-ofx-prefix which is set along with some other stuff in 
inst_gnucash()
===
     AQBANKING_OPTIONS="--enable-aqbanking"
AQBANKING_UPATH="${_OPENSSL_UDIR}/bin:${_GWENHYWFAR_UDIR}/bin:${_AQBANKING_UDIR}/bin"
     LIBOFX_OPTIONS="--enable-ofx --with-ofx-prefix=${_LIBOFX_UDIR}"
===
shouldn't all of these be in custom.sh 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 custom.sh
copy custom.sh.python.eg to custom.sh
adjust if necessary as per existing custom.sh 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... 
${exec_prefix}\Lib\site-packages
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"
============================================================================
    ERROR!
    You probably have to install the development version of the Python 
package
    for your distribution.  The exact name of this package varies among 
them.
============================================================================

See `config.log' for more details
===

something similar was experienced by Rayalan as described on 
http://wiki.gnucash.org/wiki/Windows/Development#Python_Bindings

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?

-- 
Wm