In article <4f3cd403.7070...@v.loewis.de>, "Martin v. Lowis" <mar...@v.loewis.de> wrote:
> > There are two issues that I know of for OS X. One is just getting a > > python2 symlink into the bin directory of a framework build. That's > > easy. > > Where exactly in the Makefile is that reflected? ISTM that the current > patch already covers that, since the framwork* targets are not concerned > with the bin directory. When a framework build is enabled in configure, several additional targets from Mac/Makefile are called from the main Makefile. The creating of the links in the framework bin directory and in $prefix/bin (/usr/local/bin) are handled there. (See the checked in patch for 2.7 for gory details: http://hg.python.org/cpython/rev/499796937b7a) > > The other is managing symlinks (python, python2, and python3) > > across framework bin directories; currently there's no infrastructure > > for that. That part will probably have to wait until PyCon. > > What is the "framework bin directory"? The links are proposed for > /usr/local/bin resp. /usr/bin. The proposed patch already manages > these links across releases (the most recent install wins). The framework bin directory is a bin directory within a framework. The default location for 2.7 is: /Library/Frameworks/Python.framework/Versions/2.7/bin This is where the python executable, aux programs like idle, 2to3, pydoc, python-config, as well as all Distutils-installed scripts go. Mac/Makefile and the Mac installer each optionally create symlinks from /usr/local/bin (default) to the items in the framework bin directory at build or install time for the standard items but not for subsequent Distutils-installed scripts. Normally, the /usr/local/bin links are not needed with framework builds as the framework bin directory is added to the user's $PATH during installation. > If you are concerned about multiple feature releases: this is not an > issue, since the links are just proposed for Python 2.7 (distributions > may also add them for 2.6 and earlier, but we are not going to make > a release in that direction). It is more of an issue for multiple Python 3 versions. But the whole mechanism of managing multiple framework versions (2 and/or 3) is messy right now. But that's a separate topic that I plan to address later. As for now, I believe all that is needed for PEP 394 is now checked-in. -- Ned Deily, n...@acm.org _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
