
Interesting problem: sometimes you want to build extensions with a newer version of the compiler than the python interpreter was built with. Sometimes you want to be smarter than the machine, so it would be very handy to have some manual override in msvccompiler.py, in get_build_version(), perhaps something like: if os.environ.has_key('MSVC_VERSION'): return float(os.environ['MSVC_VERSION']) This allows you as the smart developer to force the compilation of the extension to use whatever compiler version you set your environment to; if you don't set it, the system does what it does now. Thoughts? -Ivan

Hey Scott, I understand the complexities and I also understand your concerns, the problem I'm trying to solve is that in some (albeit) rare cases, I know that I can, and in fact, need to, compile an extension with a different version of the compiler than the python interpreter was built with. I currently have to modify the installed modules in the python std library to do this. It seems to me that a solution that's put into that code that is disabled by default, but allows experienced developers to more finely tune the environment they are developing under is a better thing. I'm not saying the solution I proposed is however the best way to do that, it's just the one that I came up with that a) requires the minimum of code changes and b) the minimum of work for the developers who want to use it...I think! --Ivan

Hey Scott, I understand the complexities and I also understand your concerns, the problem I'm trying to solve is that in some (albeit) rare cases, I know that I can, and in fact, need to, compile an extension with a different version of the compiler than the python interpreter was built with. I currently have to modify the installed modules in the python std library to do this. It seems to me that a solution that's put into that code that is disabled by default, but allows experienced developers to more finely tune the environment they are developing under is a better thing. I'm not saying the solution I proposed is however the best way to do that, it's just the one that I came up with that a) requires the minimum of code changes and b) the minimum of work for the developers who want to use it...I think! --Ivan
participants (2)
-
Ivan R. Judson
-
Scott David Daniels