Re: AM_PATH_PYTHON

[Alexandre Duret-Lutz]

>>> "ac" == Andrew Collier <address@hidden> writes:

 ac> From: address@hidden
 ac> Subject: AM_PATH_PYTHON
 ac> To: address@hidden
 ac> Date: Fri, 22 Nov 2002 16:52:53 +0200

Hi Andrew, 

Ahem.  Yes, this is an answer to a three-month-old mail...
Thanks for the report, happy new year, and sorry for the delay.

 ac> hello,

 ac> i have been using AM_PATH_PYTHON but find the following a
 ac> bit troublesome: the definition of PYTHON_PREFIX in
 ac> python.m4:

 ac> AC_SUBST([PYTHON_PREFIX], ['${prefix}'])

 ac> is problematic in that one cannot use the PYTHON_PREFIX
 ac> elsewhere in the configure.in script (for example to
 ac> indicate location of extra libraries in AC_CHECK_LIB) as
 ac> the definition ${prefix} is not expanded.

Indeed.  Please do not use PYTHON_PREFIX for this purpose;
just define your own variable aside.

 ac> would it not be better to define it as follows:

 ac> PYTHON_PREFIX=`$PYTHON -c "import sys; print sys.prefix"`
 ac> AC_SUBST(PYTHON_PREFIX)

The reason we can't expand '${prefix}' in $PYTHON_PREFIX is that
$PYTHON_PREFIX is used to define other Python directory variables,
and the GNU Coding Standards require we support the following
invocation to relocate a package at install-time:

 `make prefix=/foo install' 

If we replace PYTHON_PREFIX with an expanded string, the above
command will not install Python files under /foo.


Actually AM_PATH_PYTHON only offers support to compile, install,
or run Python scripts, not to build Python modules written in C
or to link an application with Python.  No wonder you don't find
AM_PATH_PYTHON appropriate...  I've seen macros for the latter
use, though: Google for AM_CHECK_PYTHON_HEADERS and
AM_CHECK_PYTHON_LIB.
-- 
Alexandre Duret-Lutz