[Python-Dev] Adventures with x64, VS7 and VS8 on Windows
"Martin v. Löwis"
martin at v.loewis.de
Mon May 21 23:29:51 CEST 2007
> 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
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
>> 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
>>> * 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
>> 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
I doubt that could work in practice. You will have to rewrite everything
to make it pass the correct command line switches.
More information about the Python-Dev