Subject: Re: AM_PATH_PYTHON
Newsgroups: gmane.comp.sysutils.automake.bugs
Date: 2003-01-22 22:33:37 GMT (5 years, 37 weeks, 6 days, 3 hours and 20 minutes ago)
>>> "ac" == Andrew Collier <colliera <at> nu.ac.za> writes:
ac> From: colliera <at> nu.ac.za
ac> Subject: AM_PATH_PYTHON
ac> To: bug-automake <at> gnu.org
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