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.
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.
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.)
Bug reported by Hartmut Goebel and patch contributed by Carl Robben.
Carl tested the fix and we have a buildbot with rpm installed, so I’m
committing even though I could not run this test (but I do understand
the changed code :)
- Actually check the contents of the file created by bdist_dumb.
- Don’t use “RECORD” as filename for non-PEP 376 record file
- Don’t start method name with “_test”, it smells like a disabled test
method instead of an helper method
- Fix some idioms (assertIn, addCleanup)
- First, support.fixup_build_ext (already used to set proper
library_dirs value under Unix shared builds) gains the ability to
correctly set the debug attribute under Windows debug builds.
- Second, the filename for the extension module gets a _d suffix under
debug builds.
- Third, the test code properly puts our customized build_ext object
into an internal dictionary to make sure that the install command will
later use our object instead of re-creating one. That’s the downside
of using low-level APIs in our test code: we have to manually push
knobs and turn handles that would otherwise be handled behind the
scenes.
Thanks to Nadeem for the testing.
- First, support.fixup_build_ext (already used to set proper
library_dirs value under Unix shared builds) gains the ability to
correctly set the debug attribute under Windows debug builds.
- Second, the filename for the extension module gets a _d suffix under
debug builds.
- Third, the test code properly puts our customized build_ext object
into an internal dictionary to make sure that the install command will
later use our object instead of re-creating one. That’s the downside
of using low-level APIs in our test code: we have to manually push
knobs and turn handles that would otherwise be handled behind the
scenes.
Thanks to Nadeem for the testing.
* Use str.startswith(tuple): I didn't know this Python feature, Python rocks!
* Replace sometimes sys.platform.startswith('linux') with
sys.platform == 'linux'
* sys.platform doesn't contain the major version on Cygwin on Mac OS X
(it's just 'cygwin' and 'darwin')
I made a note a month ago that install --record wrote incorrect entries
for extension modules (I think the problem was that the first character
of the file was stripped), so I’m now adding a test to try to reproduce
that in the current versions.
I made a note a month ago that install --record wrote incorrect entries
for extension modules (I think the problem was that the first character
of the file was stripped), so I’m now adding a test to try to reproduce
that in the current versions.
I need to copy this file in another test too, so I moved the support
code to distutils.tests.support and improved it:
- don’t skip when run from the Lib/distutils/tests directory
- use proper skip machinery instead of custom print/return/test suite
fiddling.
I need to copy this file in another test too, so I moved the support
code to distutils.tests.support and improved it:
- don’t skip when run from the Lib/distutils/tests directory
- use proper skip machinery instead of custom print/return/test suite
fiddling.
A reminder: distutils only gets bug fixes. Cosmetic changes, especially
in tests, are not worth the time spent, and can even make future merges
of bugfixes a bit less easy.
The changed behavior of sdist in 3.1 broke packaging for projects that
wanted to use a manually-maintained MANIFEST file (instead of having a
MANIFEST.in template and letting distutils generate the MANIFEST).
The fixes that were committed for #8688 (76643c286b9f by Tarek and
d54da9248ed9 by me) did not fix all issues exposed in the bug report,
and also added one problem: the MANIFEST file format gained comments,
but the read_manifest method was not updated to handle (i.e. ignore)
them. This changeset should fix everything; the tests have been
expanded and I successfully tested the 2.7 version with Mercurial, which
suffered from this regression.
I have grouped the versionchanged directives for these bugs in one place
and added micro version numbers to help users know the quirks of the
exact version they’re using.
Initial report, thorough diagnosis and patch by John Dennis, further
work on the patch by Stephen Thorne, and a few edits and additions by
me.
We don't need to create a temporary buffered binary or text file object just to
create an empty file.
Replace also os.fdopen(handle).close() by os.close(handle).
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.
Georg Brandl
Ned Deily
Richard Oudkerk
Vinay Sajip
Martin v. Löwis
doko@ubuntu.com
Antoine Pitrou
David Malcolm
Nick Coghlan
Brian Curtin
Éric Araujo
Jesus Cea
Jason R. Coombs
Florent Xicluna
Mark Hammond
Victor Stinner
Nadeem Vawda
Senthil Kumaran