[Distutils] MSToolkit and --debug-on-release for MSVCCompiler

[Mike C. Fletcher]

M.-A. Lemburg wrote:
...

>> The debug-on-release recipe consists entirely of altering the 
>> compile_options and ldflags_shared properties of the compiler 
>> object.  Problem is, the compiler API assumes that debug is a boolean 
>> flag, and AFAICT, has no access to the options the user passed in to 
>> whatever command is calling the compiler.   As a result, it looks 
>> like it would be
>> necessary to provide a compiler sub-class, one where specifying debug 
>> causes a debug-on-release set of options to be used.  That seems 
>> silly, as it's just a feature of the MSVC compilers.  Still, don't 
>> see any other elegant way to approach the problem.  That said, this 
>> is a comparatively minor feature (which I'm told isn't really a 
>> *great* idea, no matter how practical/useful), so no big deal to keep 
>> having people do it with diffs.
>
>
> Perhaps I'm missing something, but I don't really see the advantage here.
> If I call
>
> python setup.py build --debug
>
> I do get proper MSVC debug builds (provided I have the Python debug
> libs installed) of distutils based extensions.

Sure, but if you have a project with, for instance, all of wxPython, 
PyOpenGL, PyPgSQL, Numpy, mxBase, and a few other sundry extensions and 
all you want to do is track down a shallow error in your application's 
tiny little extension, then that "provided" becomes a serious PITA.

Many dependencies require all sorts of setup to provide resources before 
they can be built (jpeg and png libraries, tcl/tk installations, 
postgresql client libraries, etceteras).  Recursively building 
*everything* debug through the entire dependency tree can take days (and 
you're pretty much certain at *some* point you're going to be linking to 
a non-debug library anyway, after all, AFAIK there *is* no debug version 
of, for instance, OpenGL or GLU on Windows).

> I'm not even sure whether it's a good idea to mix debug and
> non-debug builds of libs due to the different ways they do
> memory allocation (but this might be a red herring).

Yes, that's what people keep telling me :) .  As mentioned, though, I'm 
neither too worried about getting *this* recipe in, nor particularly 
concerned with the propriety of it (since it's proved useful and 
practical on any number of occasions for me and I can keep patching the 
msvccompiler manually when I need it).  I just figured there may be 
others out there in the same boat who'd like the functionality available 
w/out the patching fuss.

BTW, I've never actually seen a new failure appear after switching to 
the debug-on-release versions of a project, but that could just be a fluke.

Have fun,
Mike

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com