[Distutils] MSToolkit and --debug-on-release for MSVCCompiler
mal at egenix.com
Tue Oct 19 09:54:23 CEST 2004
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:
> debug-on-release howto:
> Enjoy yourselves,
> Mike C. Fletcher
> Designer, VR Plumber, Coder
> Distutils-SIG maillist - Distutils-SIG at python.org
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 ! ::::
More information about the Distutils-SIG