The backport of ensurepip to 2.7.9 allows pip to optionally be installed
or upgraded using the bundled pip provided by the new ensurepip module.
The option can be specified persistently using the configure option:
./configure --with-ensurepip[=upgrade|install|no]
It can also be overridden on either the "install" or "altinstall" targets:
make [alt]install ENSUREPIP=[upgrade|install|no]
For Python 2, the default option is "no" (do not install pip).
OS X framework builds already created versioned symlinks for all
executables and scripts installed in the framework bin directory,
of the general form ${cmd} - ${cmd}2.7. The changes here add a
hierarchy of ${cmd} -> ${cmd}2 -> ${cmd}2.7. Per previous
practice, all of the links are created in the framework bin
directory for both the install and altinstall targets. This is
consistent with the long-standing recommendation to manage multiple
framework versions by adding and ordering framework bin directories
on $PATH. Also, per past practice, symlinks to all framework bin
entries are created in $prefix/bin (by default, /usr/local/bin)
for the install target and only versioned links are created for
altinstall, although the use of these links is not recommended
for framework builds and their installation is optional with
the standard OS X installers.
framework install of Python in your home directory (on OSX):
$ configure --enable-framework=${HOME}/Library/Frameworks
$ make && make install
Without this patch the framework would get installed just fine,
but 'make install' would try to install the application bundles
and command-line tools outside the user's home, which doesn't work
for non-admin users (and is bad form anyway).
to changes in how the BASECFLAGS and CFLAGS
variables get filled by configure.
The Mac/Makefile.in change ensures that
pythonw gets build with the rigth deployment
targets.
- Issue #7714: Use ``gcc -dumpversion`` to detect the version of GCC on
MacOSX.
- Make configure look for util.h as well as libutil.h. The former
is the header file that on OSX contains the defition of openpty.
(Needed to compile for OSX 10.4 on OSX 10.6)
- Use the correct definition of CC to compile the pythonw executable
The previous implementation used execv(2) to run the real interpreter, which means that
you cannot use the arch(1) tool to select the architecture you want to use for a
universal build because that only affects the python/pythonw wrapper and not the actual
interpreter.
The new version uses posix_spawnv with a number of OSX-specific options that ensure that
the real interpreter is started using the same CPU architecture as the wrapper, and that
means that 'arch -ppc python' now actually works.
I've also changed the way that the wrapper looks for the framework: it is now linked to
the framework rather than hardcoding the framework path. This should make it easier to
provide pythonw support in tools like virtualenv.
This patch adds a new configure argument on OSX:
--with-universal-archs=[32-bit|64-bit|all]
When used with the --enable-universalsdk option this controls which
CPU architectures are includes in the framework. The default is 32-bit,
meaning i386 and ppc. The most useful alternative is 'all', which includes
all 4 CPU architectures supported by MacOS X (i386, ppc, x86_64 and ppc64).
This includes limited support for the Carbon bindings in 64-bit mode as well,
limited because (a) I haven't done extensive testing and (b) a large portion
of the Carbon API's aren't available in 64-bit mode anyway.
I've also duplicated a feature of Apple's build of python: setting the
environment variable 'ARCHFLAGS' controls the '-arch' flags used for building
extensions using distutils.
This introduces a new configure option: --with-framework-name=NAME
(defaulting to 'Python'). This allows you to install several copies
of the Python framework with different names (such as a normal build
and a debug build).
Ned Deily
Ronald Oussoren
Mark Dickinson