configure should check for Python.h before enabling Python

[Daniel Morissette]

I have a system here on which GDAL's configure decides to enable the Python bindings by default, but my build fails because I do not have Python.h on my system. I have to explicitly set --without-python for my build to complete.

I think the AM_PATH_PYTHON macro (m4/acinclude.m4) should check that Python.h is present before enabling this option.

Here is the error I get at build time:

gcc -fPIC   -Wall -fPIC -O2   -I/home/mapgears/fgs-dev/src/gdal-1.3.2/port -I/home/mapgears/fgs-dev/src/gdal-1.3.2/gcore -I/home/mapgears/fgs-dev/src/gdal-1.3.2/alg -I/home/mapgears/fgs-dev/src/gdal-1.3.2/ogr -I/home/mapgears/fgs-dev/src/gdal-1.3.2/ogr/ogrsf_frmts -I/usr/include/python2.4 -I/usr/include/python2.4 -DOGR_ENABLED -I/home/mapgears/fgs-dev/src/gdal-1.3.2/port -I/home/mapgears/fgs-dev/built/unixODBC -I/home/mapgears/fgs-dev/built/unixODBC/include -I/home/mapgears/fgs-dev/built/libecw//include -I/home/mapgears/fgs-dev/built/jpeg -I/home/mapgears/fgs-dev/built/jpeg/include -I/home/mapgears/fgs-dev/built/libgeotiff/include -I/home/mapgears/fgs-dev/built/tiff/include -I/home/mapgears/fgs-dev/built/libpng -I/home/mapgears/fgs-dev/built/libpng/include -I/home/mapgears/fgs-dev/built/netcdf -I/home/mapgears/fgs-dev/built/netcdf/include  -c -o gdal_wrap.o gdal_wrap.c
gdal_wrap.c:44:20: error: Python.h: No such file or directory
gdal_wrap.c:78: error: expected specifier-qualifier-list before ‘PyObject’
gdal_wrap.c:83: error: expected specifier-qualifier-list before ‘PyObject_HEAD’
...
... followed by hundreds of errors/warnings...

[Daniel Morissette]

Note that I'm using GDAL 1.3.2 and have to stick to that version. I am unable to test whether that's fixed in 1.4.0 or CVS. However, looking in the main SVN trunk version I see some tests that try to include "Python.h" so they are likely going to fail.

If you can confirm that Python will indeed be disabled if Python.h is not found then feel free to close as invalid.

[warmerdam]

Mateusz, 

Could you look into this?  Possibly you can setup a linux system, at least
temporarily, without the python-dev package, but with the basic python and
see if you can reproduce and fix this configuration problem?

[Daniel Morissette]

FYI I just tried with GDAL 1.4.0 (the release, not the latest from SVN) and it still turns on Python by default. Here are more details:

configure output:

checking for SWIG perl bindings... disabled
checking for SWIG php bindings... disabled
checking for SWIG ruby bindings... disabled
checking for NG SWIG python bindings... disabled
checking for python... python
checking where python Makefiles are... found
checking Python makefile... found
checking where .py files should go... /usr/lib/python2.4/site-packages
checking for python headers... found
checking definitions from Python makefile... done
checking for special pymod link hacks... default
checking for NumPy include files... missing
checking if local/include already standard... no, everything is ok

...
  Traditional Python:        yes
  NG SWIG Bindings:


The AM_PATH_PYTHON macro runs the following code to set the include path:

import sys
includepy = "%s/include/python%s" % (sys.prefix, sys.version[:3])
if sys.version[0] > "1" or sys.version[2] > "4":
  libpl = "%s/include/python%s" % (sys.exec_prefix, sys.version[:3])
else:
  libpl = "%s/'$PYLIB'/python%s/config" % (sys.exec_prefix, sys.version[:3])
print "-I%s -I%s" % (includepy, libpl)


... which evaluates to this on my system:

-I/usr/include/python2.4 -I/usr/include/python2.4

However, the /usr/include/python2.4 directory contains no Python.h header. Here is what it contains:

$ ls -lR /usr/include/python2.4
/usr/include/python2.4:
total 0
drwxr-xr-x 2 root root 112 2007-01-05 17:08 Numeric

/usr/include/python2.4/Numeric:
total 24
-rw-r--r-- 1 root root 15316 2005-11-04 01:02 arrayobject.h
-rw-r--r-- 1 root root  6703 2004-09-28 13:37 ufuncobject.h

[Mateusz Łoskot]

Fixed in r10911.

Here is full changeset:
http://trac.osgeo.org/gdal/changeset/10911

Now, if Python development files are not detected and macro PYTHON_DEV is set to no, none of Python bindings are built.

Frank,
Should I also commit it back to the branches/1.4 ?

I mark this bug as FIXED.
Please verify if it works as expected for you, so I can close it.

[Mateusz Łoskot]

Frank,

I've forgot to mention one important detail.
I've not committed new version of regenerated ./configure script, so please update it.
Or may be I can do it, then please provide me with some instructions how should I prepare "official" ./configure.

Locally, I always run ./autogen.sh and the new ./configure is generated well.
Would it be enough for official ./configure or I have to use special versions of autotools, etc. ?

[warmerdam]

Configure regenerated in trunk.

[Daniel Morissette]

VERIFIED.

I copied the configure script from SVN trunk into my GDAL 1.4.0 source tree on that machine and reran it and now it does the right thing: it detects that Python.h is missing and does not enable Python.

New configure output:

checking for SWIG perl bindings... disabled
checking for SWIG php bindings... disabled
checking for SWIG ruby bindings... disabled
checking for NG SWIG python bindings... disabled
checking for python... python
checking for location of Python Makefiles... found
checking for top-level Makefile for Python... found
checking where to install Python modules... /usr/lib/python2.4/site-packages
checking for location of Python headers... found
checking definitions from top-level Python Makefile... found
checking for Python.h header... not found
configure: WARNING:
*** Could not compile test program with Python.h included, so Python bindings for GDAL will not be built.
*** Check if you have installed development version of the Python package for your distribution.
checking for Python NumPy headers... not found
checking if local/include already standard... no, everything is ok

...
  Traditional Python:        no
  NG SWIG Bindings:          no

[Mateusz Łoskot]

Applied to the stable branch 1.4 (r11556)