[Distutils] [Python-Dev] Adventures with x64, VS7 and VS8 on Windows

[Kristján Valur Jónsson]

First of all, I have put some work into pcbuild8 recently and it works
well.  I am trying to drum up momentum for work on PCBuild8
next europython.  See http://wiki.python.org/moin/EuroPython2007Sprints


> -----Original Message-----
> From: python-dev-bounces+kristjan=ccpgames.com at python.org
>
> 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.  It
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.

> I would personally like to see Python "skip" VS 2005 altogether,
> as it will be soon superceded by Orcas. Unfortunately, it's unclear
> how long Microsoft will need to release Orcas (and also, when Python
> 2.6 will be released), so I would like to defer that question by
> a few months.
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.

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.

> The MSI packaging would need to be changed, certainly. It currently
> detects the architecture it needs to package by looking at the file
> type of python.exe; that would have to be changed to give it an
> explicit parameter what architecture to package, or have it package
> all architectures it can find.

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:
1) supplying python.dll as a Side By Side assembly
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)
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.



> I'd rather make it a platform-specific definition (for platform=Windows
> API). Correct me if I'm wrong, but isn't wchar_t also available in VS
> 2003 (and even in VC6?). And doesn't it have the "right" definition in
> all these compilers?
>
> So +1 for setting Py_UNICODE to wchar_t on Windows.

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.

Kristjan