MacPorts automake and python

[David Evans]

On 3/20/14 3:01 PM, Adam Mercer wrote:
> On Thu, Mar 20, 2014 at 4:51 PM, Eric A. Borisch <eborisch at macports.org> wrote:
>
>> I think the issue here is that automake is getting patched to *only* support
>> MacPorts-managed builds, but really automake should still be available for
>> use to build non-MP software.
> Agreed, that's one of the main concerns I have with this.
I don't see this as MacPorts specific.  Instead it correctly determines
the default PYTHON_PREFIX
for the Python in use.  This is a MacPorts path only because you are
using a MacPorts Python port
>= 2.5.  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.

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.

>
>> What was broken that needed fixing (by the original change)? Is there a
>> particular port that needed the change? Is there another way to fix it
>> without modifying automake?
>>
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. 

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.

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.

Thanks

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?



Dave