[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2] autoconf: fix python-dev detection on old python versions



2012/3/30 Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
> On Fri, 2012-03-30 at 08:35 +0100, Roger Pau Monne wrote:
>> Replaced the use of python-config (that is only present in Python >= 2.5.x)
>> with the distutils python module.
>>
>> Please run ./autogen.sh after applying the patch.
>>
>> Again, this has only been tested on OS X Python 2.7.
>>
>> Changes since v1:
>>
>> Â* Added Python LDFLAGS to library test.
>>
>> Signed-off-by: Roger Pau Monne <roger.pau@xxxxxxxxxxxxx>
>> Cc: Zhang, Yang Z <yang.z.zhang@xxxxxxxxx>
>> Cc: KUWAMURA Shin'ya <kuwa@xxxxxxxxxxxxxx>
>> Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
>> ---
>> Âtools/m4/python_devel.m4 | Â 36 +++++++++++++++++-------------------
>> Â1 files changed, 17 insertions(+), 19 deletions(-)
>>
>> diff --git a/tools/m4/python_devel.m4 b/tools/m4/python_devel.m4
>> index 3bcca7b..dada92a 100644
>> --- a/tools/m4/python_devel.m4
>> +++ b/tools/m4/python_devel.m4
>> @@ -1,27 +1,25 @@
>> ÂAC_DEFUN([AX_CHECK_PYTHON_DEVEL], [
>> +ac_python_version=`$PYTHON -c 'import distutils.sysconfig; \
>> + Â Âprint distutils.sysconfig.get_config_var("VERSION")'`
>> Âac_previous_cppflags=$CPPFLAGS
>> -CPPFLAGS="$CFLAGS `$PYTHON-config --includes`"
>> +CPPFLAGS="$CFLAGS `$PYTHON -c 'import distutils.sysconfig; \
>> + Â Âprint "-I" + distutils.sysconfig.get_config_var("INCLUDEPY")'`"
>> +CPPFLAGS="$CPPFLAGS `$PYTHON -c 'import distutils.sysconfig; \
>> + Â Âprint distutils.sysconfig.get_config_var("CFLAGS")'`"
>
> This mixes up CPPFLAGS and CFLAGS in what looks like a very strange way
> to me, is it right?

Yes, this is kind of a work around, since the header preprocessor
check ignores CFLAGS and only uses CPPFLAGS, so if CFLAGS are used,
the preprocessor check fails, although the header is there.

>
> [...]
>
>> +LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
>> + Â Âprint distutils.sysconfig.get_config_var("LIBS")'`"
>> +LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
>> + Â Âprint "-L" + distutils.sysconfig.get_python_lib(plat_specific=1,\
>> + Â Âstandard_lib=1) + "/config"'`"
>> +LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
>> + Â Âprint distutils.sysconfig.get_config_var("LINKFORSHARED")'`"
>
> Elsewhere in the Xen build system we would call these LDLIBS_<blah>
> and/or SHLIBS_<blah> (see tools/Rules.mk for examples). I think in the
> case of libpython, which is not built in tree you would only want to use
> SHLIBS_PYTHON.
>
> On a similar note do we really want to add the python stuff to the
> global CFLAGS and LDFLABS etc? Wouldn't it be better to have
> CFLAGS_PYTHON etc and to use them explicitly in tools/python/Makefile
> rather than using them for all compilations?

This is only added to CFLAGS/LDFLAGS temporary, to perform the checks,
and on the build system they are automatically added by setup.py.

> Although that might require other build system changes which could be
> done later in the interests of fixing getting a fix for people using
> python 2.3/2.4 into the tree.
>
>> +LDFLAGS="$LDFLAGS `$PYTHON -c 'import distutils.sysconfig; \
>> + Â Âprint distutils.sysconfig.get_config_var("LDFLAGS")'`"
>> +
>> ÂAC_CHECK_HEADER([Python.h], [],
>> Â Â Â[AC_MSG_ERROR([Unable to find Python development headers])],)
>> -AC_CHECK_LIB($python_lib, PyArg_ParseTuple, [],
>> +AC_CHECK_LIB(python$ac_python_version, PyArg_ParseTuple, [],
>> Â Â Â[AC_MSG_ERROR([Unable to find a suitable python development library])])
>> ÂCPPFLAGS=$ac_previous_cppflags
>> ÂLDLFAGS=$ac_previous_ldflags
>
>

I will have to check again, maybe python-config script has the clue to
what parameters have to be passed to link against libpython. I'm in a
hurry, so I don't think I will have time to look into this until the
following week, sorry (I'm not leaving it apart).

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.