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

["Martin v. Löwis"]

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

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

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

Why?

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

> 4) Signing the python dlls and executables

Hmm.

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

Regards,
Martin