MacPorts automake and python

Eric A. Borisch eborisch at macports.org
Thu Mar 20 15:38:49 PDT 2014


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).

devans at macports, what was the reason for the change? I don't see a ticket
referenced?

  - Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20140320/987a5fd0/attachment-0001.html>


More information about the macports-dev mailing list