MacPorts automake and python

[Sean Farley]

David Evans <devans at macports.org> writes:

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

That is not the issue here. It is *real* simple, son: ./configure
--prefix=$HOME doesn't work anymore. The change needs to be reverted
immediately and some other workaround provided.