- 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.
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 added a link from the term “virtual subclass” to the glossary entry
for ABCs but this was not enough, now the glossary briefly defines
“virtual” and links to the abc module doc which contains more mentions
of virtual subclasses.
``code`` markup is enough to mark command-line fragments or to talk
about a character. ``'c'`` is still used for actual Python string
objects. I did a similar change in optparse.rst in r86521.
I’ve also ported two minor changes from the 3.3 version of the file
(removing an unnecessary module name in a class directive, adding a
comma).
I made the doc for the compat alias BadZipfile shorter and used a
directive to document deprecation.
I figured there was no point of talking about zipfile.error (“the old
name” that’s older than the other old name BadZipfile) in the 3.x docs
so I just removed it.
