(based on the fruitfull meating I had with Ned after the language summit at Pycon '11)

Running configure on a MacOSX system will set MACOSX_DEPLOYMENT_TARGET to 10.4, which is probably not optimal for anyone on a recentish system.  It would be better to set the deployment target to something more recent. There seem to be two options:

* set the deployment target to the current OS release by default
  (that is, 10.6 on a Snow Leopard system, 10.4 on a Tiger system)

* set the deployment target to 10.4 on OSX 10.4 and 10.5 on 
  later versions.

Setting it to the version of the current OS is probably the least surprising. 


Related to this: configure --enable-universalsdk selects the 10.4u SDK
by default. That would have to be changed at the same time, setting
the deployment target to 10.6 while still trying to use files from
the 10.4u SDK is not very useful.

I'd set the default value of the SDK to '/' on anything newer than OSX 10.4 and keep the 10.4u SDK on OSX 10.4 (because you cannot build universal binaries using the default system headers on a lot of 10.4 systems).

I'll work on a patch for the default branch during the sprints, and interesting question is if this should be backported.

> Running configure on a MacOSX system will set
> MACOSX_DEPLOYMENT_TARGET to 10.4, which is probably not optimal
> for anyone on a recentish system.

What's more, when I first tried to compile Python on Mac OS X, and I have MacPorts' version of Python as the default interpreter in the terminal, I get the following errors when trying to do bare `./configure; make`:

bash-3.2$ make 
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
Traceback (most recent call last):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 553, in <module>
    main()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 535, in main
    known_paths = addusersitepackages(known_paths)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 268, in addusersitepackages
    user_site = getusersitepackages()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 243, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 233, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/sysconfig.py", line 535, in get_config_var
    return get_config_vars().get(name)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/sysconfig.py", line 434, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/sysconfig.py", line 313, in _init_posix
    raise IOError(msg)
IOError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.4" but "10.6" during configure
make: *** [Include/Python-ast.h] Error 1


I worked around this by adding MACOSX_DEPLOYMENT_TARGET=10.6 to the configure script, but I have to remember to do that every time I configured a fresh clone of the source.

See Issue11487 for more discussion on the SDK issue.

As a workaround do "touch  Include/Python-ast.*" to ensure that the build won't try to rebuild the header files (those files are up-to-date, but the timestamps in a fresh checkout are the same as those of the source file and that causes a rebuild)

>Setting it to the version of the current OS is probably the least surprising. 
Agreed.

The 10.4 SDK needs to be changed in 2.7, 3.1 and 3.2 as well: the most recent version of Xcode no longer ships with the 10.4 SDK (and possibly  without the 10.5 SDK as well, I'll writing this at the airport and haven't downloaded the latest release yet).

For 3.3.0, ./configure (configure.ac) was modified in 688d48e434e4 for Issue13590 to use more appropriate defaults for universal builds on newer releases. In particular, --enable-universalsdk=yes uses the Xcode default SDK (as returned by xcodebuild) instead of the 10.4u SDK (not included with Xcode 4), --with-universal-archs now defaults to "intel" if ppc support is not available, and MACOSX_DEPLOYMENT_TARGET defaults to the OS level for 10.6 and newer systems (rather than using 10.4 or 10.3 by default). It also attempts to avoid building Python with deprecated and problematic Apple llvm-gcc compiler, using clang instead.  The defaults can be overridden by providing explicit arguments and/or environment variables to ./configure (--enable-universalsdk, --with-universal-archs, CC, MACOSX_DEPLOYMENT_TARGET).  While not 100% perfect, the 3.3 changes give good defaults for nearly all common universal build configurations on 10.4 through 10.8.

2.7.x and 3.2.x have the same problems; attached are patches that backport the 3.3 configure changes to them.  However, they do introduce a potential incompatibility.  Currently, 2.7 and 3.2 initial configures set MACOSX_DEPLOYMENT_TARGET by default to 10.4 (10.3 on a PPC system) for non-universal builds or 32-bit universal builds and to 10.5 for other universal builds.  For 3.3, those values are still used for 10.4 and 10.5 systems; for 10.6 and later systems, the default deployment target is now the OS level itself (10.6 for builds on 10.6, etc).  Changing the default deployment target for more recent systems has some benefits: the most obvious is that readline support linking with the system BSD libedit is now enabled by default.  The potential incompatibility is that the deployment target value is used by distutils.util.get_platform() to form the platform name which is used for bdist names (like eggs) and the lib build directory for the standard library build.  While I haven't verified that this is the case, if you've built Python 2.7.2, say, from source on 10.6+ and installed some extension modules with Distutils, then would build from a new release with the proposed patches and install to the existing install location without reinstalling the extension modules, there might be a chance of unexpected incompatibilities between the old extension module (built to an older deployment target) and the upgraded interpreter.  Perhaps somewhat more likely is that an extension module binary distribution available on PyPI was available for the old deployment target (10.4) but not for the new target (10.6). Also, it is possible that differences in behavior might be introduced by a change in default compiler.  All of these potential incompatibilities can be avoided by overriding the changed defaults, either at Python build time with arguments to ./configure or at extension module build time with environment variables or Distutils config files.  Introducing such changes is clearly acceptable with a new release, such as 3.3.  For existing releases, it can be argued that the newer, more appropriate settings can also be obtained by just overriding the old defaults ("Explicit is better than implicit.").  The question then is, when the old default behavior no longer makes sense due to changes outside of our control, do the benefits of changing them in a maintenance release outweigh the risk of introducing an incompatibility?

If they are applied, some or all of the changes to the Mac/README file should be backported as well. Also, while working on this, I did find one edge case where the ./configure defaults do not produce a buildable configuration.  The case is on 10.6 with (the optional) Xcode 4.  For universal builds, the test added early in ./configure to determine if ppc is supported doesn't work.  Since the correct compiler hasn't been determined yet, the test looks at the architectures in /usr/lib/libSystem.dylib.  On 10.6, unfortunately, that (and other libs) is a 3-way universal files (i386, x86_64, and ppc) even in the 10.6 SDK supplied with Xcode 4.2 for 10.6 despite the fact that the compilers provided with 4.x do not support building ppc binaries.  The problem shows up right away as the "make" dies quickly and it is easily fixed by specifying --with-universal-archs=intel.  Still, it would be nice to fix that.

New changeset ee8e4b61d6181f5bfadf6ee3d229f0ebda8a6ae9 by Ned Deily in branch '2.7':
[2.7] Backport macOS universal build and installer fixes from 3.6. (GH-6469)
https://github.com/python/cpython/commit/ee8e4b61d6181f5bfadf6ee3d229f0ebda8a6ae9

Update: as of 3.6.5 and 2.7.15 and in the upcoming 3.7.0 release, macSO framework builds with --enable-universalsdk=/ no longer add -isysroot=/ to compiler and linker calls.  They are not necessary and made it more difficult to attempt to override.  Although we still do not officially support building on newer macOS systems for older systems (due to lack of "weak link" testing support and issues with setup.py and configure), it should now be possible to more easily use the Apple build tool chain features documented for xcrun, like the DEVELOPER_RUN and SDKROOT environment variables (see 'man xcrun').  This includes current python.org macOS installer builds.  So I think we can finally close this.  Thanks all!