I'm using the full-blown VS.NET 2003, as given to a number of python-dev people by Microsoft a number of years ago. This appears to come with the SDK and a 64bit compiler.
Not sure what it makes it appear to you that way - it doesn't. VS.NET 2003 is x86 only
I'm guessing vsextcomp doesn't use the Visual Studio 'ReleaseAMD64' configuration - would it be OK for me to check in changes to the PCBuild projects for this configuration?
Please don't. It exclusively relies on vsextcomp, and is only useful if you have that infrastructure installed. See for yourself: it uses the /USE_CL:MS_OPTERON command line switch, which isn't a Microsoft invention (but instead invented by Peter Tröger).
So is there something we can do to make distutils play better with binaries built from PCBuild8, even though it is considered temporary?
In what way better? It already supports them just fine, AFAICT. I guess you are referring to the support for building extensions on top of a source tree "installation". I doubt that is used that often (but I understand you are using it).
It seems the best thing might be to modify the PCBuild8 build process so the output binaries are in the ../PCBuild' directory - this way distutils and others continue to work fine. Does that sound reasonable?
I think Kristjan will have to say a word here: I think he just likes it the way it is right now. That would rather suggest that build_ext needs to be changed.
I've no objection to that - but I'd like to help keep the pain to a minimum for people who find themselves trying to build 64bit extensions in the meantime.
I recommend that those people install the official binaries. Why do you need to build the binaries from source, if all you want is to build extensions?
In C or in C++? In C++, wchar_t is a builtin type, just like short, int, long. So there is no further formal definition.
This was in C++, but the problem was really WCHAR, as used by much of the win32 API.
But in C, WCHAR should not be a problem (and I would like to see explicit source code and explicit compiler error message to be proven wrong).
* Finally, as something from left-field which may well take 12 months or more to pull off - but would there be any interest to moving the Windows build process to a cygwin environment based on the existing autoconf scripts? What compiler would you use there? I very much like using the VS debugger when developing on Windows, so that capability should not go away.
You would use whatever compiler the autoconf toolset found. Recent versions know enough about MSVC for simple projects. Many people would need to take care that their environment pointed at the correct compiler - especially the person building releases.
But assuming MSVC was found and had the appropriate switches passed, there would be no impact on the ability to use Visual Studio as a debugging environment.
I doubt that could work in practice. You will have to rewrite everything to make it pass the correct command line switches. Regards, Martin