On cygwin, the setup.py script uses unixccompiler.py for compiling and linking
C extensions. The unixccompiler.py script assumes that executables do not get
special extensions, which makes sense for Unix.  However, on Cygwin,
executables get an .exe extension.

This causes a problem during the configuration step (python setup.py config),
in which some temporary executables may be generated. As unixccompiler.py does
not know about the .exe extension, distutils fails to clean up after itself: it
does not remove _configtest.exe but tries to remove _configtest instead.

The attached patch to unixccompiler.py sets the correct exe_extension for
cygwin by checking if sys.platform is 'cygwin'. With this patch, distutils
cleans up after itself correctly.

Michiel de Hoon
University of Tokyo, Human Genome Center.

After some more reflection (and no negative feedback), I am reverting the
original patch and applying my version, cygwinccompiler.py-shared.diff,
instead.

My reasons are the following:

1. support for older toolchains is retained
2. support for new toolchains (i.e., ld -shared) is added

The goal of my approach is to avoid breaking older toolchains while adding
better support for newer ones.

The cygwinccompiler.get_versions() function only handles versions numbers of
the form "x.y.z".  The attached patch enhances get_versions() to handle "x.y"
too (i.e., the ".z" is optional).

This change causes the unnecessary "--entry _DllMain@12" link option to be
suppressed for recent Cygwin and Mingw toolchains. Additionally, it directs
recent Mingw toolchains to use gcc instead of dllwrap during linking.

Currently, the cygwinccompiler.py compiler handling in
distutils is invoking the cygwin and mingw compilers
with the -static option.

Logically, this means that the linker should choose to
link to static libraries instead of shared/dynamically
linked libraries.

Current win32 binutils expect import libraries to have
a .dll.a suffix and static libraries to have .a suffix.
If -static is passed, it will skip the .dll.a
libraries. This is pain if one has a tree with both
static and dynamic libraries using this naming
convention, and wish to use the dynamic libraries.

The -static option being passed in distutils is to get
around a bug in old versions of binutils where it would
get confused when it found the DLLs themselves.

The decision to use static or shared libraries is site
or package specific, and should be left to the setup
script or to command line options.

   This patch makes it work again.

    specified with an absolute path, the object file is also
    written to an absolute path.  The patch drops the drive and
    leading '/' from the source path, so a path like /path/to/foo.c
    results in an object file like build/temp.i686linux/path/to/foo.o.

levels.  (Previously, -vvv would be the same as -q!)

[Patch #684398] Rename verbose argument to show-response; don't conditionalize the get_classifiers() call

split into OPT and BASECFLAGS (Makefile.pre.in rev. 1.108), because
now there are essential CFLAGS in BASECFLAGS.

when compiling .RC files.

From Robin Dunn, fixes SF # 669198.

want it to be.  Log both the old and new mode.

   have two tuples listing the legal keywords for setup() and Extension()

executable.

    (Power Macintosh -> Power_Macintosh)

   Add the 'register' distutils command

  Add 'classifiers' keyword to DistributionMetadata

This adds a --relative option to the bdist_dumb command that defaults
to false; if true, the .tar.gz or .zip will be assembled using relative
paths.

bdist_wininst.py we will see.)

Removed the base64 encoded binary contents, wininst.exe must be in the
same directory as this file now.

wininst.exe must be recompiled and commited each time the sources in
PC/bdist_wininst are changed.

        Previously archive_util.py attempted to spawn an
        external 'zip' program for the zip action, if this fails, an
        attempt to import zipfile.py is made...

        This bites folks who have 'old' or non-conforming zip
        programs on windows platforms.  This change tries the 'zipfile'
        module first, falling back to spawning a zip process if
        the module isn't available.

    suggested by PEP 291.