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

Mike C. Fletcher mcfletch at rogers.com
Mon Oct 18 23:40:18 CEST 2004

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.

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:

debug-on-release howto:

Enjoy yourselves,

  Mike C. Fletcher
  Designer, VR Plumber, Coder

More information about the Distutils-SIG mailing list