<br><br>On Thursday, March 20, 2014, Sean Farley <<a href="javascript:_e(%7B%7D,'cvml','sean@macports.org');" target="_blank">sean@macports.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Adam Mercer <<a>ram@macports.org</a>> writes:<br>
<br>
> On Thu, Mar 20, 2014 at 4:01 PM, Sean Farley <<a>sean@macports.org</a>> wrote:<br>
><br>
>> Before: my project installed into /path/foo/a<br>
>> After: my project installed into /path/foo/b<br>
><br>
> Got you, if I configured using: ./configure --prefix=$HOME/opt<br>
><br>
> the the Python modules would be installed in:<br>
> $HOME/opt/lib/python2.7/site-packages<br>
><br>
> After the change it wants to install them in:<br>
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/<br>
<br>
Ok, yeah, that's what I was wondering. Hacking autotools to change this<br>
behavior is ludicrous. This change most certainly needs to be<br>
reverted.<br>
<br>
Honestly, I don't know why we're messing with automake at all. If this<br>
is just to make installing ports (from the perspective of the portfile<br>
author) easier then why can't this type of change go in the python<br>
portgroup?<br>
</blockquote><div><br></div><div>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).<span></span></div>
<div><br></div>devans@macports, what was the reason for the change? I don't see a ticket referenced?<div><br></div><div> - Eric</div>