may differ between sysconfig and distutils.sysconfig due to
compiler customizations on OS X. For now, move those vars
into a separate test and skip if the customization has taken
place in distutils. The long-term solution is to eliminate
having two sysconfig modules.
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.
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.
These regex changes fix a number of issues for distutils on Windows:
- #6884: impossible to include a file starting with 'build'
- #9691 and #14004: sdist includes too many files
- #13193: test_filelist failures
This commit replaces the incorrect changes done in 0a94e2f807c7 and
90b30d62caf2 to fix#13193; we were too eager to fix the test failures
and I did not study the code enough before greenlighting patches. This
time we have unit tests from the problems reported by users to be sure
we have the right fix.
Thanks to Nadeem Vawda for his help.
These regex changes fix a number of issues for distutils on Windows:
- #6884: impossible to include a file starting with 'build'
- #9691 and #14004: sdist includes too many files
- #13193: test_filelist failures
This commit replaces the incorrect changes done in 0a94e2f807c7 and
90b30d62caf2 to fix#13193; we were too eager to fix the test failures
and I did not study the code enough before greenlighting patches. This
time we have unit tests from the problems reported by users to be sure
we have the right fix.
Thanks to Nadeem Vawda for his help.
The code used to call os.path.join to build a regex but without escaping
the backslash, which lead to test failures on Windows. Antoine Pitrou
fixed it in 0a94e2f807c7 by enhancing the code to accept both / and \,
with proper escaping, but in my opinion this goes against the distutils
feature freeze, hence this change.
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.)
Ned Deily
Richard Oudkerk
Vinay Sajip
Martin v. Löwis
doko@ubuntu.com
Antoine Pitrou
David Malcolm
Georg Brandl
Nick Coghlan
Brian Curtin
Éric Araujo