Issue #22919: Windows build updated to support VC 14.0 (Visual Studio 2015), which will be used for the official 3.5 release.

Patch from Thomas Kluyver.

due to possible uninitialized _config_vars.  Original patch by Alex Gaynor.

Change stacklevel in warnings.warn() for 'SO' key to 2.

is overriden with the CC environment variable, use the new compiler as
the default for linking if LDSHARED is not also overriden.  This restores
Distutils behavior introduced in 3.2.3 and inadvertently dropped in 3.3.0.

  when imported, instead doing it at build time.  This makes importing
  sysconfig faster and reduces Python startup time by 20%.

  two makefile macros SHLIB_SUFFIX and EXT_SUFFIX. SO now has the value of
  SHLIB_SUFFIX again (as in 2.x and 3.1). The SO macro is removed in 3.4.

  the package.

    In particular, fix extension module build failures when trying to use
    32-bit-only installer Pythons on systems with Xcode 4 (currently
    OS X 10.8, 10.7, and optionally 10.6).
    * Backport 3.3.0 fixes to 3.2 branch (for release in 3.2.4)
    * Since Xcode 4 removes ppc support, extension module builds now
      check for ppc compiler support and by default remove ppc and
      ppc64 archs when they are not available.
    * Extension module builds now revert to using system installed
      headers and libs (/usr and /System/Library) if the SDK used
      to build the interpreter is not installed or has moved.
    * Try to avoid building extension modules with deprecated
      and problematic Apple llvm-gcc compiler.  If original compiler
      is not available, use clang instead by default.

    In particular, fix extension module build failures when trying to use
    32-bit-only installer Pythons on systems with Xcode 4 (currently
    OS X 10.8, 10.7, and optionally 10.6).
    * Backport 3.3.0 fixes to 2.7 branch (for release in 2.7.4)
    * Since Xcode 4 removes ppc support, extension module builds now
      check for ppc compiler support and by default remove ppc and
      ppc64 archs when they are not available.
    * Extension module builds now revert to using system installed
      headers and libs (/usr and /System/Library) if the SDK used
      to build the interpreter is not installed or has moved.
    * Try to avoid building extension modules with deprecated
      and problematic Apple llvm-gcc compiler.  If original compiler
      is not available, use clang instead by default.

  use _PYTHON_PROJECT_BASE in distutils/sysconfig.py.

tailoring for universal builds by factoring out common OS X-specific
customizations from sysconfig, distutils.sysconfig, distutils.util,
and distutils.unixccompiler into a new module _osx_support that can
eventually also be used by packaging.

Closes #15366: Corrected computation of include location for source builds. Thanks to Richard Oudkerk for the bug report and patch.

- fix test_distutils and test_sysconfig test failures by
  aligning sysconfig and distutils.sysconfig tailoring of
  configure variables (as in 2.7)

- Try to avoid building Python or extension modules with problematic
  llvm-gcc compiler.
- Since Xcode 4 removes ppc support, extension module builds now
  check for ppc compiler support and automatically remove ppc and
  ppc64 archs when not available.
- Since Xcode 4 no longer install SDKs in default locations,
  extension module builds now revert to using installed headers
  and libs if the SDK used to build the interpreter is not
  available.
- Update ./configure to use better defaults for universal builds;
  in particular, --enable-universalsdk=yes uses the Xcode default
  SDK and --with-universal-archs now defaults to "intel" if ppc
  not available.

has left two versions of customize_compiler, the original in
distutils.sysconfig and another copy in distutils.ccompiler, with some
parts of distutils calling one and others using the other.
Complete the revert back to only having one in distutils.sysconfig as
is the case in 3.x.

Distutils-based packages with C extension modules may fail because
Apple has removed gcc-4.2, the version used to build python.org
64-bit/32-bit Pythons.  If the user does not explicitly override
the default C compiler by setting the CC environment variable,
Distutils will now attempt to compile extension modules with clang
if gcc-4.2 is required but not found. Also as a convenience, if
the user does explicitly set CC, substitute its value as the default
compiler in the Distutils LDSHARED configuration variable for OS X.
(Note, the python.org 32-bit-only Pythons use gcc-4.0 and the 10.4u
SDK, neither of which are available in Xcode 4.  This change does not
attempt to override settings to support their use with Xcode 4.)

Distutils-based packages with C extension modules may fail because
Apple has removed gcc-4.2, the version used to build python.org
64-bit/32-bit Pythons.  If the user does not explicitly override
the default C compiler by setting the CC environment variable,
Distutils will now attempt to compile extension modules with clang
if gcc-4.2 is required but not found. Also as a convenience, if
the user does explicitly set CC, substitute its value as the default
compiler in the Distutils LDSHARED configuration variable for OS X.
(Note, the python.org 32-bit-only Pythons use gcc-4.0 and the 10.4u
SDK, neither of which are available in Xcode 4.  This change does not
attempt to override settings to support their use with Xcode 4.)

Fix closes Issue11439 Remove the SVN keywords from the code as it is no longer applicable in hg. Patch Contributed by Neil Muller.

set the MACOSX_DEPLOYMENT_TARGET env variable for the interpreter process
on OS X.  This could cause failures in non-distutils subprocesses and was
unreliable since tests or user programs could modify the interpreter
environment after distutils set it.  Instead, have distutils set the
the deployment target only in the environment of each build subprocess.

Continue to use the previous algorithm for deriving the deployment target
value:
    if MACOSX_DEPLOYMENT_TARGET is not set in the interpreter's env:
        use the interpreter build configure MACOSX_DEPLOYMENT_TARGET
    elif the MACOSX_DEPLOYMENT_TARGET env value >= configure value:
        use the env MACOSX_DEPLOYMENT_TARGET
    else: # env value less than interpreter build configure value
        raise exception
This allows building extensions that can only run on newer versions of
the OS than the version python was built for, for example with a python
built for 10.3 or later and an extension that needs to be built for 10.5.

set the MACOSX_DEPLOYMENT_TARGET env variable for the interpreter process
on OS X.  This could cause failures in non-distutils subprocesses and was
unreliable since tests or user programs could modify the interpreter
environment after distutils set it.  Instead, have distutils set the
the deployment target only in the environment of each build subprocess.

Continue to use the previous algorithm for deriving the deployment target
value:
    if MACOSX_DEPLOYMENT_TARGET is not set in the interpreter's env:
        use the interpreter build configure MACOSX_DEPLOYMENT_TARGET
    elif the MACOSX_DEPLOYMENT_TARGET env value >= configure value:
        use the env MACOSX_DEPLOYMENT_TARGET
    else: # env value less than interpreter build configure value
        raise exception
This allows building extensions that can only run on newer versions of
the OS than the version python was built for, for example with a python
built for 10.3 or later and an extension that needs to be built for 10.5.

Without this patch python will fail to start properly when the environment
variable MACOSX_DEPLOYMENT_TARGET is set on MacOSX and has a value that is
not compatible with the value during Python's build. This is caused by code
in sysconfig that was only meant to be used in disutils.

Without this patch python will fail to start properly when the environment
variable MACOSX_DEPLOYMENT_TARGET is set on MacOSX and has a value that is
not compatible with the value during Python's build. This is caused by code
in sysconfig that was only meant to be used in disutils.

This was overlooked in r80804.  This change is not really a bug fix,
but the release manager agreed to it.  There is no NEWS entry, like
in the original commit.

This was done in r80805 (#7908) and erroneously brought back by the
distutils revert.  This commit removes more code than the original,
which was uncomplete.  There is no NEWS entry, like in r80805.

during the build from setup.py.

handler to parse the Makefile file. Avoid a UnicodeDecodeError if the source
code directory name contains a non-ASCII character and the locale encoding is
ASCII.

svn+ssh://pythondev@svn.python.org/python/branches/py3k

........
  r85353 | antoine.pitrou | 2010-10-10 11:37:12 +0200 (dim., 10 oct. 2010) | 3 lines

  Issue #9437: Fix building C extensions with non-default LDFLAGS.
........