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)

  for host compiler.

Patch by Jakub Wilk.

Patch by Jakub Wilk.

python executable

The __os_install_macro defines some post-processing activities during an rpm
build; one of the scripts it calls is brp-python-bytecompile, which can take
an argument: the python executable with which to byte-compile .py files in the
package payload.

In some older versions of rpm (e.g. in RHEL 6), this invocation doesn't pass
in an argument, and brp-python-bytecompile defaults to using /usr/bin/python,
which can lead to the .py files being byte-compiled for the wrong version of
python.  This has been fixed in later versions of rpm by passing in
%{__python} as an argument to brp-python-bytecompile.

Workaround this by detecting if __os_install_post has a 0-argument invocation
of brp-python-bytecompile, and if so generating an equivalent macro that has
the argument, and explicitly provide the new definition within the specfile.

python executable

The __os_install_macro defines some post-processing activities during an rpm
build; one of the scripts it calls is brp-python-bytecompile, which can take
an argument: the python executable with which to byte-compile .py files in the
package payload.

In some older versions of rpm (e.g. in RHEL 6), this invocation doesn't pass
in an argument, and brp-python-bytecompile defaults to using /usr/bin/python,
which can lead to the .py files being byte-compiled for the wrong version of
python.  This has been fixed in later versions of rpm by passing in
%{__python} as an argument to brp-python-bytecompile.

Workaround this by detecting if __os_install_post has a 0-argument invocation
of brp-python-bytecompile, and if so generating an equivalent macro that has
the argument, and explicitly provide the new definition within the specfile.

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

Patch by Ralf Schmitt.