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