>> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
