MacPorts automake and python

[Sean Farley]

Eric A. Borisch <eborisch at macports.org> writes:

> On Thursday, March 20, 2014, Sean Farley
> <sean at macports.org<javascript:_e(%7B%7D,'cvml','sean at macports.org');>>
> wrote:
>
>>
>> Adam Mercer <ram at macports.org> writes:
>>
>> > On Thu, Mar 20, 2014 at 4:01 PM, Sean Farley <sean at macports.org> wrote:
>> >
>> >> Before: my project installed into /path/foo/a
>> >> After:  my project installed into /path/foo/b
>> >
>> > Got you, if I configured using: ./configure --prefix=$HOME/opt
>> >
>> > the the Python modules would be installed in:
>> > $HOME/opt/lib/python2.7/site-packages
>> >
>> > After the change it wants to install them in:
>> >
>> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/
>>
>> Ok, yeah, that's what I was wondering. Hacking autotools to change this
>> behavior is ludicrous. This change most certainly needs to be
>> reverted.
>>
>> Honestly, I don't know why we're messing with automake at all. If this
>> is just to make installing ports (from the perspective of the portfile
>> author) easier then why can't this type of change go in the python
>> portgroup?
>>
>
> That's what I was trying to get at - my guess it is not py-* ports that
> benefitted from the change, but ports that include some pythonic parts.
> Fixing one or two problem ports would be a better fix than patching the
> build environment (automake).

Yes, I wholeheartedly agree. Having ./configure --prefix=$HOME install
python parts into MacPorts' prefix is just plain bananas.