[Python-Dev] Adventures with x64, VS7 and VS8 on Windows
"Martin v. Löwis"
martin at v.loewis.de
Mon May 21 23:43:39 CEST 2007
>> I don't find the need to have separate object directories convincing:
>> For building the Win32/Win64 binaries, I have separate checkouts
>> *anyway*, since all the add-on libraries would have to support
>> multi-arch builds, but I think they don't.
> No they don't, but that doesn't mean that you need different checkouts
> for python, only the others. Anyway, this is indeed something I'd like
> to see addressed. I don't think we should ditch cross-compilation.
Nobody proposed to ditch cross-compilation. I very much like
cross-compilation, I do all Itanium and AMD64 in cross-compilation.
I just want the *file structure* of the output to be the very same
for all architectures, meaning that they can't coexist in a single
> should simplify a lot of stuff, including buildbot setup and so on (if
> we get the buildbot infrastructure to support it). It is also very
> cumbersome, if you are working on a project, to have the binaries all
> end up in the same place. Doing interactive work on python, I frequently
> compile both the 32 bit and 64 bit versions for testing and it would
> be downright silly to have to rebuild everything every time.
No, you use two checkouts, of course.
> I think this is a bit unrealistic. Here we are in the middle of 2007,
> VS2005 has just got SP1, and VS2003 is still the "official" compiler.
> PCBuild8 is ready, it just needs a little bit of extra love and
> buildbots to make us able to release PGO versions of x86 and x64.
No matter what the next compiler is (VS 2005 or VS 2007/2008), it's
still *a lot* of work until the VS 2005 build can be used for releasing
Python. For example, there is no support for the SxS installation of
msvcr8.dll, using the MSI merge module.
> Given the delay for getting even this far, waiting for Orcas and then
> someone to create PCBuild9, and then getting it up and running and so on
> will mean waiting another two years.
No. I would expect that either the PCbuild or PCbuild8 project files can
be used with little changes to build using VS9. I just tried, and it
works reasonably well.
> I am not familiar with the msi packaging process at all. But here is
> something we should start to consider: VISTA support. This could mean
> some of:
Not sure whether anything really is needed. Python works fine on Vista.
> 1) supplying python.dll as a Side By Side assembly
What would that improve?
> 2) Changing python install locations
> 3) Supporting shadow libraries, where .pyc files end up in a different
> hierarchy from the .py files. (useful for many things beside VISTA)
Yes, and people had written PEPs for it which failed due to lack of
> 4) Signing the python dlls and executables
> 5) Providing user level manifests.
> Vista adoption is going very fast. We see 10% of our users have moved
> to vista and rising.
Sure, and have they reported problems with Python on Vista (problems
specific to Vista?)
> Yes. Btw, in previous visual studio versions, wchar_t was not treated
> as a builtin type by default, but rather as synonymous with unsighed short.
> Now the default is that it is, and this causes some semantic differences
> and incompatibilities of the type seen.
C or C++? According to the standards, it ought to be a builtin,
primitive type in C++, and a typedef in C.
More information about the Python-Dev