I think getting this bug fixed would be really nice from a user experience point of view.

I've further into this for my own setup, which is Python 3.3 64-bit, Visual C++ Express 2010 and the Windows SDK v7.1 (plus service packs), which is probably a typical setup for a user looking to build Python extensions without paying for a compiler. Here's what I've noticed, apart from the fact that msvccompiler9.py is a mess.

query_vcvarsall executes "vcvarsall.bat amd64 & set". The first part, trying to delegate to another batch file that doesn't exist, will fail. So no environment variables will be set, but the PATH environment variable always exists, hence "ValueError: ['path']".

The DISTUTILS_USE_SDK environment variable is useless, even leaving aside the fact that MsSdk also needs to be defined. The idea is that distutils will trust that the user has set the appropriate environment variables (e.g. SetEnv.Cmd /Release). However, successful compilation of 64-bit extensions won't rely on this variable at all:

1. DISTUTILS_USE_SDK/MsSdk defined, SetEnv not called: "cl.exe" and friends can't be resolved and nothing works.

2. DISTUTILS_USE_SDK/MsSdk defined, SetEnv called: "cl.exe" and friends can be resolved and everything works.

3. DISTUTILS_USE_SDK/MsSdk undefined, SetEnv not called: "vcvarsall.bat amd64" will fail and we end up with "ValueError: ['path']" as above.

4. DISTUTILS_USE_SDK/MsSdk undefined, SetEnv called: in query_vcvarsall, "vcvarsall.bat amd64" still fails, but it doesn't matter at this point, because the environment variables INCLUDE, LIB, LIBPATH and PATH will exist, so parsing "vcvarsall.bat amd64 & set" works. This doesn't guarantee linking with the correct bitness, but one would hope so :)


I believe SetEnv.Cmd can be found using HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDKTools or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDKTools.