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

[M.-A. Lemburg]

Mike C. Fletcher wrote:
> The MS Toolkit compiler recipe I put together for building Python 2.4 
> extensions currently requires manually diff-ing the source of 
> msvccompiler.py, as does my recipe for building a single extension with 
> debug information so that developers can track down bugs in their code 
> (without needing to rebuild dozens of other modules and core python in 
> debug mode).
> 
> The changes are pretty trivial in both cases, so I'm looking for 
> feedback on whether I should go with sub-classing as separate compiler 
> modules, or whether the changes should be integrated into the core 
> compiler code-base.
> 
> 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.

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).

> The more important issue, is the MSToolkit compiler.  Here the logic of 
> creating a sub-class of msvccompiler seems obvious, but doing so doesn't 
> seem necessary from a technical standpoint...
> Overriding load_macros and get_msvc_paths is no problem, but the changes 
> to get_msvc_paths should, if I read correctly, actually fix one of the 
> long-standing annoyances (having to run the GUI at least once to get the 
> registry keys, even though the vcvars.bat variables are already 
> specifying everything necessary).  This is coded in such a way that it 
> simply replaces the "you should run the GUI" error message with an 
> attempt to retrieve the variables from the environment (i.e. the only 
> case where you run it is where you would have failed with an error before).
> 
> The changes to load_macros shouldn't interfere with MSVC operation in 
> the least (they are done as a try:except: which is only used when the 
> MSVC operation fails).
> 
> MSToolkit howto:
> http://www.vrplumber.com/programming/mstoolkit/
> 
> debug-on-release howto:
> http://groups.google.ca/groups?selm=mailman.26.1065949224.2192.python-list%40python.org 
> 
> 
> Enjoy yourselves,
> Mike
> 
> ________________________________________________
>  Mike C. Fletcher
>  Designer, VR Plumber, Coder
>  http://www.vrplumber.com
>  http://blog.vrplumber.com
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 19 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::