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%4...
Enjoy yourselves, Mike
________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@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 ! ::::