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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel