Forcing the macOS IDLE.app gui process to launch in 32-mode was
a necessary hack for old versions of Tk (Aqua Carbon as in Tk 8.4
and early versions of 8.5); it is not needed for current versions
of Tk.  Since 32-bit launching will no longer be supported on
future releases of macOS, allow IDLE.app to launch in 64-bit mode.

upgrade pip by default, using the bundled pip provided by the new ensurepip
module.  A new configure option, --with-ensurepip[=upgrade|install|no], is
available to override the default ensurepip "--upgrade" option.  The option
can also be set with "make [alt]install ENSUREPIP=[upgrade|install\no]".

in bin directories for all configurations: non-framework vs framework,
and single arch vs universal builds.  pythonx.y-32 is now always
installed for 64-bit/32-bit universal builds.  The obsolete and
undocumented pythonw* symlinks are no longer installed anywhere.

This mitigates the current Aqua Tk refresh problem on OS X 10.9
by backporting 2.7.x behavior and is transparent to the user.

- Remove OS X installer and Mac/Makefile dependencies on /Developer which
  no longer exists with Xcode 4; the referenced tools have been installed
  into the usr/bin tool root since Xcode 3.
- Support adding the SDK usr/bin tool root to the installer's PATH via the
  SDK_TOOLS_BIN environment variable.

installer package from the OS X Makefile for Python 3.  It has
never worked on Python 3 and is not needed there as pre-10.3.9
installs are no longer supported.

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.

ensure "make install" creates symlinks in --prefix bin for the "-32"
files in the framework bin directory like the installer does.

ensure "make install" creates symlinks in --prefix bin for the "-32"
files in the framework bin directory like the installer does.

OS X installers no longer includes an Extras directory.  The Tools
directory is now installed in the framework under share/doc.

        Extras (/Applications/Python 3.n/Extras/) where the Demo
        directory had previous been installed.

        scripts (implemented in #10679).

2to3-2.7, while a versioned copy is installed of other tools and a versioned copy of2to3 is installed by python 2.6, 3.1 and the 3.2 alpha.

install python binaries that support all
architectures in a universal build.

svn+ssh://pythondev@svn.python.org/python/trunk

........
  r80647 | ronald.oussoren | 2010-04-30 13:20:14 +0200 (Fri, 30 Apr 2010) | 11 lines

  Fix for issue #3646: with this patch it is possible to do a
  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).
........

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

* Ensure that framework install works given the
  recent CFLAGS and BASECFLAGS changes

the recent changes to CFLAGS and BASECFLAGS.

changes to CFLAGS and BASECFLAGS handling

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.

works on osx 10.5

a 32-bit executable (which is needed because not all (GUI) libraries are available in 64-bit mode)

Also fixes a typo in Mac/README

svn+ssh://pythondev@svn.python.org/python/trunk

........
  r78755 | ronald.oussoren | 2010-03-07 10:04:06 +0100 (Sun, 07 Mar 2010) | 3 lines

  Fix for issue #7998: pythonw didn't work when --with-framework-name was
  specified
........

specified

- 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

svn+ssh://pythondev@svn.python.org/python/trunk

........
  r77031 | ronald.oussoren | 2009-12-24 14:30:58 +0100 (Thu, 24 Dec 2009) | 15 lines

  Issue #6834: replace the implementation for the 'python' and 'pythonw' executables on OSX.

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

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.

Fix symlink for 2to3 in framework install. Without this patch an incorrect link is created when DESTDIR is set.

* Re-enable installation of files in /usr/local/bin in the OSX installer
  because those files no longer clash with a 2.x install.

* Remove junk documentation resources from the Python.app inside the framework
  (This is a left-over from the ancient Python IDE, which was removed before 2.5)
* Ensure that the documentation is installed in a location where IDLE will see it

rename of 'python' to 'python3'