MacPorts automake and python
Adam Mercer
ram at macports.org
Thu Mar 20 15:01:07 PDT 2014
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.
> 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?
>
> Assuming the change is/was needed (and the best solution), perhaps setting
> an environment variable during MP managed builds could be used here to
> switch the behavior? Something along the lines of:
>
> AC_SUBST([PYTHON_PREFIX], [`[ ${__MP_BUILD__} ] && $PYTHON -c "import sys;
> sys.stdout.write(sys.prefix);" || echo -n ${prefix}`])
>
> where __MP_BUILD__=1 during a managed build, and undefined otherwise?
Seems that would work, but I'm not sure I like the idea of hacking the
autotools. At work I've run into a lot of bizarre problems that I
eventually traced back to different OS vendors making changes to the
autotools.
> This way when a user outside of MacPorts is installing a
> python-using-software (built against MP-provided python) and they have set
> $prefix via configure, it doesn't get crowbarred into /opt/local/ (or
> wherever MP is installed.) (Granted, as the .m4 file notes, they will need
> to set PYTHONPATH or tell python about it in some manner to use it.)
In the past when I've needed to ensure that python libraries, provided
by MacPorts, end up in the correct location I've used something like
the following:
set pythondir "${frameworks_dir}/Python.framework/Versions/2.7/lib/python2.7/site-packages"
destroot.args-append \
pythondir="${pythondir}" \
pyexecdir="${pythondir}" \
pkgpythondir="${pythondir}/${name}" \
pkgpyexecdir="${pythondir}/${name}"
It's a bit of a hack but gives full control and doesn't break things
for non MacPorts use.
Cheers
Adam
More information about the macports-dev
mailing list