MacPorts automake and python

[Adam Mercer]

On Thu, Mar 20, 2014 at 6:41 PM, David Evans <devans at macports.org> wrote:

> If you were using a Python that was installed using the
> traditional installation path then
> this would return ${prefix} as the original did.
>
> For instance using python24 returns /opt/local  (which is ${prefix) by
> our standard and others as well).
> Using /usr/bin/python (Apple build) returns
> /System/Library/Frameworks/Python.framework/Versions/2.7
>
> So the original AM_PYTHON_PATH only returns the correct result if the
> Python in use is installed in the
> 'standard' place.  Doesn't work any Python installed in a non-standard
> place.

You're getting your prefix's mixed up, before your patch
AM_PATH_PYTHON returned the prefix specified by the --prefix option to
the configure process that called it and not the MacPorts prefix. For
example using the following simple configure.ac:

AC_INIT([foo],[1.0])
AC_CONFIG_AUX_DIR([gnuscripts])
AC_CONFIG_MACRO_DIR([gnuscripts])
AM_INIT_AUTOMAKE([foreign])
AC_CONFIG_FILES([Makefile])
AM_PATH_PYTHON()
AC_OUTPUT

If I use automake @1.14.1_0 then configure produces the following output:

$ ./configure --prefix=$HOME/opt
<snip>
checking for python... /opt/local/bin/python
checking for python version... 2.7
checking for python platform... darwin
checking for python script directory... ${prefix}/lib/python2.7/site-packages
checking for python extension module directory...
${exec_prefix}/lib/python2.7/site-packages
<snip>
$

Where ${prefix} is defined in Makefile as:

$ grep ^prefix Makefile
prefix = /Users/ram/opt
$

However with automake @1.14.1_1 the output is:

$ ./configure --prefix=$HOME/opt
<snip>
checking for python... /opt/local/bin/python
checking for python version... 2.7
checking for python platform... darwin
checking for python script directory...
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
checking for python extension module directory...
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
<snip>
$

The default behaviour should be to install under --prefix, not the
MacPorts location. If AM_PATH_PYTHON is not returning an appropriate
path for a given port then the port should use PYTHON_PREFIX and
PYTHON_EXEC_PREFIX as you mention below.

> Looking at the comments surrounding this code in python.m4 the upstream
> authors acknowledge this.
>
>   dnl Use the values of $prefix and $exec_prefix for the corresponding
>   dnl values of PYTHON_PREFIX and PYTHON_EXEC_PREFIX.  These are made
>   dnl distinct variables so they can be overridden if need be.  However,
>   dnl general consensus is that you shouldn't need this ability.
>
> The answer is yes, any port that uses AM_PYTHON_PATH to discover the
> Python install
> prefix will fail on MacPorts (or any other installation of Python into a
> non-standard path)
> without intervention and there are quite a few.

Then the ports themselves should be fixed, automake shouldn't be
broken in order to "fix" the ports.

> In the past this has been handled typically by applying a similar patch
> to the configure file
> provided with each project being ported.  This works and the patch here
> does not interfere
> with this because the configure file is not being regenerated.
>
> However, increasingly, ports need to use autoreconf or even autogen.sh
> to regenerate configuration
> files prior to build for some other reason (intltool perl issues for
> instance).  This again effects a
> large number of ports.  In this case, patching of the configure file is
> impractical and the required
> patch to configure.ac amounts to replacing AM_PYTHON_PATH with custom
> code that is often
> package specific.  This change to automake makes that unnecessary.

But makes MacPorts automake useless for anything outside of MacPorts.

> Have to head home now but will follow up later this evening.  In the
> meantime, please don't revert
> this change on your own as there are many ports that WILL be broken.
> If, we, as a group decide
> that that is the preferred approach, I will make the change after the
> effected ports have been re-written.

At the moment we have an automake that doesn't work, that is a major
issue and needs to be fixed ASAP. Which ports are broken without this
change? Are there tickets?

> PS What ever happened to the doctrine that if you mix code in other
> installation prefixes with MacPorts
> ports, all bets are off and results are not guaranteed?

You're thinking about the issues with installing things in /usr/local,
we're discussing something completely different.

Cheers

Adam