[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
> 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

>> 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.


More information about the Python-Dev mailing list