[Patches] [ python-Patches-462754 ] no '_d' ending for mingw32

[noreply@sourceforge.net]

Patches item #462754, was opened at 2001-09-18 20:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462754&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Häring (ghaering)
Assigned to: A.M. Kuchling (akuchling)
Summary: no '_d' ending for mingw32

Initial Comment:
This patch prevents distutils from naming the extension
modules <extname>_d.pyd when compiled with mingw32 on
Windows in debug mode. Instead, the extension modules
will get the normal name <extname>.pyd. Technically,
the patch doesn't prevent the behaviour for mingw32,
but only adds the _d for MS Visual C++ and Borland
compilers (though I don't know about the Borland case).

The reason for this? Adding "_d" doesn't make any sense
for GNU compilers. I think it's just a MS Visual C++
madness. If you want to debug an extension module that
was compiled with gcc, you have to use gdb anyway,
because the debugging symbols of MSVC++ and gcc are
incompatible. So you normally use a release Python
version (from the python.org binary download) and
compile your extensions with mingw32.

To put it shortly:

The current state is that you do a
"setup.py build --compiler=mingw32 --debug" and then
rename the extension modules, removing the _d. Then
fire up gdb to debug your module.

With this patch, the renaming isn't necessary anymore.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-09-28 13:43

Message:
Logged In: YES 
user_id=31435

All else being equal, a system emulating Unix under Windows 
should strive to make life comfortable for Unix folks.  The 
question is thus whether all else is in fact equal <wink -- 
but I don't know, as I don't yet use the system under 
discussion>.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2001-09-28 11:37

Message:
Logged In: YES 
user_id=163326

Hmm. I don't like the _d endings at all. But if the policy
on win32 is that debug executables and libraries get a "_d"
ending, then I'm unsure wether this patch should be applied.

I have plans to hack the autoconf madness to build a native
win32 Python with mingw32. But that won't be ready by
tomorror. And I don't think that I'll add "_d" endings there
for debugging, because that would be inconsistent with the
normal autoconf builds on Unix.

I'm glad that *I* don't have to decide wether this patch is
a Good Thing. Being consistent with Python win32 build or
with GNU (gcc/autoconf). Take your pick :-)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-09-18 20:46

Message:
Logged In: YES 
user_id=31435

FYI, MSVC never adds _d on its own -- Mark Hammond and/or 
Guido forced it to do that.  I don't remember why, but one 
of them explained it to me long ago and it made good sense 
at the time <wink>.

MSCV normally compiles debug and release builds into 
distinct subdirectories, and uses the same names in both.  
But *our* MSVC setup forces it to compile both flavors of 
build directly into the PCbuild directory, so has to give 
the resulting DLLs and executables different names (else 
the second build would overwrite the results of the first 
build).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462754&group_id=5470