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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-03-30 at 09:26 +0100, Roger Pau Monnà wrote:
> 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.

Which check is this?

> > [...]
> >
> >> +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.

AH, great then!

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