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

[Geert Janssens]

On Friday 09 May 2014 16:51:06 Wm Tarr wrote:
> I'm working my way through getting python enabled with "Windows from
> scratch".
> 
Great ! Will you document your success ?
> 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.
> 
My long term vision for gnucash-on-windows would be that you could run 
configure directly yourself instead of having to run install.sh every 
time. There are already ways to do so but they need manual tweaking of 
the environment.

The eventual goal is to separate the part that creates the build 
environment and the part that actually builds gnucash. The first should 
become no more than a formality. I like to think of it as a gnucash sdk 
which you download and install. Once done you can just focus on gnucash 
only and forget about the environment until you want to update/reinstall 
the sdk/environment.

Alas we're not there yet by a long shot so let's look at what is 
possible with what we have now.

Your proposal to add an environment variable seems ok to me.

> 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()
> ===
I hadn't noticed these warnings. Yet they do indeed appear in my builds 
as well. Both options are obsolete by now and I have permanently 
removed. If you run a "git pull" on the gnucash-on-windows.git directory 
these warnings should be gone in your next build.

--enable-schemas-install was from when gnucash still was using gconf for 
its preferences (2.4.x and earlier). 
--with-ofx-prefix is no longer in use since 2.4.9.


>      AQBANKING_OPTIONS="--enable-aqbanking"
> AQBANKING_UPATH="${_OPENSSL_UDIR}/bin:${_GWENHYWFAR_UDIR}/bin:${_AQBAN
> KING_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?
> 
Yes, those are good candidates as well to add to a configurable 
parameter.
> 
> 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.
> 
You do, thanks.

> 
> ==============
> 
> 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
This is different on my linux machine: the -lpython27 is not part of the 
library path. I don't think that should be an issue though.

> checking for Python site-packages path...
> c:\Python27\Lib\site-packages
> checking python extra libraries... None

This is suspicious. On my linux machine this gives
-lpthread -ldl  -lutil

> checking python extra linking flags... None

Same here:
-Xlinker -export-dynamic

> 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"

To get some idea of what goes wrong you should examine config.log. It is 
a big file in which all build output of the configure run is stored. 
Somewhere there should be an attempt to compile a small test program to 
link with the python libraries. This test compile fails for some reason 
which is not printed in the default configure output but should be in 
the log.

> ======================================================================
> ====== 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?
Those are defined in the gnucash makefiles. You shouldn't worry about 
them. These are where gnucash will install its own python related files. 
prefix and exec_prefix are known parameters during the build. You can 
read a little more about them by running './configure --help' in 
gnucash.git if you like.

> 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?
> 
Are you sure configure picks up the include/libary/site-package path 
from the environment ? I would expect they are read from python's 
pkgconfig configuration. If this configuration stores the paths in 
Windows notation, that is what you will get. But generally this 
shouldn't matter too much. Both notations can normally be used 
interchangeably (with the caveat that path name expansion on Windows 
type paths may swallow the backslashes so that needs some attention).

Good luck with your python exploration !

Geert