[PyPy-issue] [issue620] AM_CHECK_PYTHON_HEADERS fails with PyPy (pypy-config?)
Dave Malcolm
pypy-dev-issue at codespeak.net
Fri Jan 14 02:24:51 CET 2011
New submission from Dave Malcolm <dmalcolm at redhat.com>:
I'm experimenting with building the python bindings for GTK against PyPy 1.4.1
The build process for PyGTK uses GNU autoconf and automake, with this automake macro::
AM_CHECK_PYTHON_HEADERS(,[AC_MSG_ERROR(could not find Python headers)])
and I suspect there are quite a few other extension modules that use this.
The macro expands to the following test within the generated "configure" shell script::
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for headers required to compile python extensions" >&5
$as_echo_n "checking for headers required to compile python extensions... " >&6; }
py_prefix=`$PYTHON -c "import sys; print sys.prefix"`
py_exec_prefix=`$PYTHON -c "import sys; print sys.exec_prefix"`
if test -x "$PYTHON-config"; then
PYTHON_INCLUDES=`$PYTHON-config --includes 2>/dev/null`
else
PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION}"
if test "$py_prefix" != "$py_exec_prefix"; then
PYTHON_INCLUDES="$PYTHON_INCLUDES -I${py_exec_prefix}/include/python${PYTHON_VERSION}"
fi
fi
... more stuff follows, which tries to compile a simple .c file containing #include <Python.h>
Attempting::
PYTHON=pypy ./configure
fails for my RPM packages of PyPy, and presumably for the official packages of PyPy (I have the wrong libssl.so to
run them directly)::
checking whether pypy version >= 2.3.5... yes
checking for pypy version... 2.5
checking for pypy platform... linux2
checking for pypy script directory... ${prefix}/site-packages
checking for pypy extension module directory... ${exec_prefix}/site-packages
checking for headers required to compile python extensions... not found
configure: error: could not find Python headers
In the absence of a "pypy-config" in the path, it's going to use this clause::
PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION}"
fwiw, PYTHON_VERSION is obtained from running::
$PYTHON -c "import sys; print sys.version[:3]"
which for pypy-1.4.1 is "2.5"
So I believe it's looking below %{py_prefix}/include/python2.5 for a "Python.h"
However the packaging script in pypy/tool/release/package.py creates just an
"include" subdir directly below the pypydir, and copies the relevant *.h/*.inl
files there (I do something equivalent in my Fedora rpm packages)
So I believe this is likely to break building any modules built using the GNU
autotools against PyPy.
One solution for compatibility with this automake macro may be to simply
provide a "pypy-config" executable, analagous to the "python-config"
executable.
For reference, CPython generates this script from Misc/python-config.in in its Makefile:
http://svn.python.org/view/python/branches/release25-maint/Misc/python-config.in?view=log
with this substitution:
sed -e "s, at EXENAME@,$(BINDIR)/python$(VERSION)$(EXE)," < $(srcdir)/Misc/python-config.in >python-config
So perhaps PyPy's "bin" subdirectory could gain a "pypy-config" script, perhaps directly taking CPython's version
of this?
Taking the 2.5 version above, some of the options work correctly (this is on my Fedora RPM build of PyPy)::
$ pypy python-config.in --help
Usage: python-config.in [--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--help]
$ pypy python-config.in --prefix
/usr/lib64/pypy-1.4.1
$ pypy python-config.in --includes
-I/usr/lib64/pypy-1.4.1/include -I/usr/lib64/pypy-1.4.1/include
but others fail::
$ pypy python-config.in --exec-prefix
Traceback (most recent call last):
File "app_main.py", line 53, in run_toplevel
File "python-config.in", line 36, in <module>
print sysconfig.EXEC_PREFIX
AttributeError: 'module' object has no attribute 'EXEC_PREFIX'
$ pypy python-config.in --libs
Traceback (most recent call last):
File "app_main.py", line 53, in run_toplevel
File "python-config.in", line 46, in <module>
libs = getvar('LIBS').split() + getvar('SYSLIBS').split()
AttributeError: 'NoneType' object has no attribute 'split'
$ pypy python-config.in --cflags
Traceback (most recent call last):
File "app_main.py", line 53, in run_toplevel
File "python-config.in", line 42, in <module>
flags.extend(getvar('CFLAGS').split())
AttributeError: 'NoneType' object has no attribute 'split'
$ pypy python-config.in --ldflags
Traceback (most recent call last):
File "app_main.py", line 53, in run_toplevel
File "python-config.in", line 46, in <module>
libs = getvar('LIBS').split() + getvar('SYSLIBS').split()
AttributeError: 'NoneType' object has no attribute 'split'
Hopefully, providing a pypy-config script seems sane (and I can hack on this, if desired).
What's the preferred approach here (e.g. either to fix up python-config, or to provide the missing
distutils.sysconfig variables?)
(Aside: I've seen hundreds of python extension modules, and many of them use crazy non-standard build tools e.g.
handcoded Makefiles with buggy logic for finding header files, linker options etc. Getting them to build against
PyPy may throw up lots of silly "yak-shaving" issues like this, on top of the more interesting one of emulating the
CPython extension API; having a "pypy-config" may help ameliorate some of them).
----------
effort: ???
messages: 2058
nosy: dmalcolm, pypy-issue
priority: feature
release: ???
status: unread
title: AM_CHECK_PYTHON_HEADERS fails with PyPy (pypy-config?)
_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue620>
_______________________________________________________
More information about the Pypy-issue
mailing list