* In trying to build x64 from a 32bit VS7 (ie, cross-compiling via the PCBuild directory), the python.exe project fails with:

pythoncore fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'AMD64'

is this a known issue, or am I doing something wrong?

You are likely doing something wrong: a) I assume it's VS 7.1 (i.e. VS.NET 2003); VS 2002 is not supported at all b) you probably didn't install vsextcomp, but you should. In fact, you don't need all of it, but you do need the cl.exe and link.exe wrappers it comes with - they dispatch to the proper tools from the SDK c) in case it isn't clear: you also need an AMD64 compiler, e.g. from the platform SDK. Unfortunately, Microsoft keeps changing the registry settings for the SDK, so vsextcomp only knows about some selected SDKs. If that causes a problem, please let me know.

* The PCBuild8 project files appear to work without modification (I only tried native compilation here though, not a cross-compile) - however, unlike the PCBuild directory, they place all binaries in a 'PCBuild8/x64' directory. While this means that its possible to build for multiple architectures from the same source tree, it makes life harder for tools like 'distutils' - eg, distutils already knows about the 'PCBuild' directory, but it knows nothing about either PCBuild8 or PCBuild8/x64.

This is an issue to be discussed for Python 2.6. I'm personally hesitant to have the "official" build infrastructure deviate from the layout that has been in-use for so many years, as a lot of things depend on it. 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.

A number of other build processes also know to look inside a PCBuild directory (eg, Mozilla), so instead of formalizing PCBuild8, I think we should merge PCBuild8 into PCBuild.

Right - PCbuild8 should not get formalized. It probably should continue to be maintained. For 2.6, the first question to answer is: what compiler should it use? 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 understand that PCBuild8 is not "official", but in the assumption that future versions of Python will use a compiler later than VS7, it makes sense to me to clean this up now - what are others opinions on this?

Not "official" really only means "not used to build the official binaries" - just like PC/VC6. It's still (somewhat) maintained. As for cleaning it up - see above. I would *really* like to skip VS 2005 altogether, as I expect that soon after we decide to use VS 2005, Microsoft will replace it with the next release, stop supporting VS 2005, take the free compiler off the next, and so on (just like they did for VS 2003, soon after we decided to use it for 2.5).

* Re the x64 directory used by the PCBuild8 process. IMO, it makes sense to generate x64 binaries to their own directory - my expectation is that cross-compiling between platforms is a reasonable use-case, and we should support multiple achitectures for the same compiler version.

See above; I disagree. First, "multiple architectures" only means x86, AMD64, and Itanium, and I would like to drop "official" Itanium binaries from 2.6 (even though they could continue to be supported in the build process). Then, even if the Python build itself support multiple simultaneous architectures, the extension modules don't all (correct me if I'm wrong).

This would mean formalizing the x64 directory in both 'PCBuild' and distutils, and leaving other external build processes to update as they support x64 builds. Does this make sense? Would this fatally break other scripts used for packaging (eg, the MSI framework)?

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.

* Wide characters in VS8: PC/pyconfig.h defines PY_UNICODE_TYPE as 'unsigned short', which corresponds with both 'WCHAR' and 'wchar' in previous compiler versions. VS8 defines this as wchar_t, which I'm struggling to find a formal definition for beyond being 2 bytes.

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. In C (including C99), wchar_t ought to be defined in stddef.h.

My problem is that code which assumes a 'Py_UNICODE *' could be used in place of a 'WCHAR *' now fails. I believe the intent on Windows has always been "PyUNICODE == 'native unicode'" - should PC/pyconfig.h reflect this (ie, should pyconfig.h grow a version specific definition of PyUNICODE as wchar_t)?

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.

* 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. Regards, Martin

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

On 2007-05-21 12:30, Kristján Valur Jónsson wrote:

...

[Py_UNICODE being #defined as "unsigned short" on Windows]

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.

+1 from me. If think this is simply a bug introduced with the UCS4 patches in Python 2.2. unicodeobject.h already has this code: #ifndef PY_UNICODE_TYPE /* Windows has a usable wchar_t type (unless we're using UCS-4) */ # if defined(MS_WIN32) && Py_UNICODE_SIZE == 2 # define HAVE_USABLE_WCHAR_T # define PY_UNICODE_TYPE wchar_t # endif # if defined(Py_UNICODE_WIDE) # define PY_UNICODE_TYPE Py_UCS4 # endif #endif But for some reason, pyconfig.h defines: /* Define as the integral type used for Unicode representation. */ #define PY_UNICODE_TYPE unsigned short /* Define as the size of the unicode type. */ #define Py_UNICODE_SIZE SIZEOF_SHORT /* Define if you have a useable wchar_t type defined in wchar.h; useable means wchar_t must be 16-bit unsigned type. (see Include/unicodeobject.h). */ #if Py_UNICODE_SIZE == 2 #define HAVE_USABLE_WCHAR_T #endif disabling the default settings in the unicodeobject.h. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 21 2007)

...

...

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611

-----Original Message----- below appears to solve the problem, and given Martin's previous +1, I decided to stop there. I failed in a quick attempt at replacing the literal 2 with something involving sizeof. Does this look reasonable?

+1. I should add that we have this local mod in our own patched python. It does seem like a mistake that needs fixing. Kristjan

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 extensions?

...

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. Regards, Martin

Kristján Valur Jónsson wrote:

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

Addressing only the issues of PCBuild8 and 64-bit architectures, I have tried to establish "free" buildbot support for the 64-bit architectures without any real success. Should the PSF be considering paying for infrastructure that will support 64-bit build reporting?

[...]

regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden ------------------ Asciimercial --------------------- Get on the web: Blog, lens and tag your way to fame!! holdenweb.blogspot.com squidoo.com/pythonology tagged items: del.icio.us/steve.holden/python All these services currently offer free registration! -------------- Thank You for Reading ----------------

Addressing only the issues of PCBuild8 and 64-bit architectures, I have tried to establish "free" buildbot support for the 64-bit architectures without any real success.

Should the PSF be considering paying for infrastructure that will support 64-bit build reporting?

You can bring it up to the board, of course. However, given that all other buildbot machines were contributed by volunteers, the fact that nobody volunteers to contribute buildbot machines for PCbuild8 indicates that there is not a lot of interest in that build infrastructure. Note that there *are* 64-bit buildbot slaves, e.g. for AMD64 (contributed by Neal Norwitz), Alpha (contributed by Neal Norwitz), Itanium (contributed by Matthias Klose, offering a machine from the Debian project), and PPC64 (likewise). These machines all run Linux or Tru64, and (to my understanding) serve other purposes as well, making the buildbot slave just a minor detail. It's an unfortunate fact of life that Microsoft Windows does not support multi-tasking multi-user workloads that well, so the Windows buildbot slave are (to my knowledge) typically dedicated machines (except for Tim's machine, which is just disconnected from the master when he doesn't feel like running buildbot jobs). Regards, Martin

However, I think people ask much too often for a debugging build; in many cases, they could work happily with a release build that supports debugging. Depending on the problem you try to solve, you may or may not need debug information for pythonxy.dll as well, or just for your extension module.

While that is true in theory, I often find it is not the case in practice, generally due to the optimizer. Depending on what magic the compiler has done, it can be very difficult to set breakpoints (conditional or otherwise), inspect variable values, etc. It is useful in some cases, but very often I find myself falling back to a debug build after attempting to debug a local release build.

I think there are several other cases in distutils to support special cases (e.g. the DISTUTILS_USE_SDK environment variable); if people want to see their setup supported, AND ARE WILLING TO CONTRIBUTE: more power to them.

Yes, but I believe its also important to solicit feedback on the best way to achieve their aims. In this particular case, I believe it would have been misguided for me to simply check in whatever was necessary to have distutils work from the PCBuild8 directory. I hope it is clear that I am willing to contribute the outcome of these discussions... Cheers, Mark

-----Original Message----- From: "Martin v. Löwis" [mailto:martin@v.loewis.de] Sent: Tuesday, May 22, 2007 05:33 To: Steve Holden Cc: Kristján Valur Jónsson; Mark Hammond; distutils-sig@python.org; python-dev@python.org Subject: Re: Adventures with x64, VS7 and VS8 on Windows

...

Addressing only the issues of PCBuild8 and 64-bit architectures, I have tried to establish "free" buildbot support for the 64-bit architectures without any real success.

Should the PSF be considering paying for infrastructure that will support 64-bit build reporting?

You can bring it up to the board, of course. However, given that all other buildbot machines were contributed by volunteers, the fact that nobody volunteers to contribute buildbot machines for PCbuild8 indicates that there is not a lot of interest in that build infrastructure. Most people just install whatever it is that they are offered to download. For me, the most compelling reason to provide the new builds is

the 15% performance benefit. If there are no technical and corporate difficulties, such as firewalls and security, I am sure that CCP can provide a VisualStudio2005 buildbot for our needs. Wasn't there some issue that each buildbot can only provide a single build? Here is a place where cross-compilation comes into its own again. Kristjan

-----Original Message-----

...

...

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.

Someone mentioned the idea to have a bat file do it. I like that idea. There is already a build.bat file which will build whatever configuration you choose (platform and configuration). Extending it to subsequently copy the resulting binaries up one level is easy. Perhaps this is an acceptable compromise? Kristjan

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 extensions?

I've been following this discussion and it seems like an appropriate place to mention such a scenario which I have encountered myself and am still trying to work around: I have a set of extensions that use SWIG to wrap my own C++ library. This library, on a day-to-day basis is built against VS8 since the rest of our product suite is. Right now I have no way to work with this code using VS8 since the standard distribution is built against VS7 which uses a different CRT. This is an absolute nightmare in practice since I currently have to maintain VS7 projects in parallel with the standard VS8 ones simply so that I can run and test my python code. I've downloaded the Python source and had a look at building up my own distributions for each case (ideally there would be an easy way to separate out Release / Debug products as well as the VS8 / VS7 variants, and I guess potentially for those cross-compiling we'd need to go a step further and do this per arch as well. Anyway, this isn't how it works at the moment, but I'm still searching for a way to be able to work on the python code in VS8. Building using the current projects I seem to get everything in the PCBuild8 / PCBuild dirs. How can I work with what is build? Is there a shell script to build a final distribution tree? If not, is there a simple way to build an MSI similar to the one found on the Python.org site for the official releases but using the PCBuild8 stuff? If not how do you recommend getting myself to a state where I have at least a feature complete distribution build against VS8? I'm happy with a one time build that I can just install into my source tree and upload to the SCM. Thanks in advance, and I hope that my thoughts proved useful in some way. Jamie

While that is true in theory, I often find it is not the case in practice, generally due to the optimizer. Depending on what magic the compiler has done, it can be very difficult to set breakpoints (conditional or otherwise), inspect variable values, etc. It is useful in some cases, but very often I find myself falling back to a debug build after attempting to debug a local release build.

What I typically do is to disable optimization in a release build. It then essentially becomes a debug build, except that _DEBUG is not defined, so that it doesn't incorporate the debug CRT. This, in turn, means that you can mix such a "debug" build readily with non-debug binaries.

...

I think there are several other cases in distutils to support special cases (e.g. the DISTUTILS_USE_SDK environment variable); if people want to see their setup supported, AND ARE WILLING TO CONTRIBUTE: more power to them.

Yes, but I believe its also important to solicit feedback on the best way to achieve their aims. In this particular case, I believe it would have been misguided for me to simply check in whatever was necessary to have distutils work from the PCBuild8 directory. I hope it is clear that I am willing to contribute the outcome of these discussions...

Sure - all understood, and all fine. It's certainly good to build consensus first, but in cases of "should we support that borderline case of build setup as long as I'm willing to maintain it", the answer should always be "yes" (*), irrespective of the merits of the specific proposal. Heck, we would even accept patches to support HP-UX better :-) Regards, Martin (*) assuming it doesn't break anything P.S. I think there have been cases where I haven't been that supportive wrt. build issues. However, in this case I really feel "go ahead".

Surely there are differences between architectures? PC uses MSI after all. Why can't linux be under trunk/linux and pc 86 under trunk/pcbuild8/win32PGO and 64 under trunk/pcbuild8/x64pgo?

That couldn't work for me. I try avoid building on a network drive, and with local drives, I just can't have a Windows build and a Linux build on the same checkout - they live on separate file systems, after all (Linux on ext3, Windows on NTFS, with multi-boot switching between them).

That´s just silly. And two visual studios open, and edit the file in two places too?

I have about 10 checkouts of Python, on different machines, with no problems. I don't feel silly doing so. I don't *use* them simultaneously, of course - I cannot work on two architectures simultaneously, anyway.

I say let's just admit that tools can compile for more than one target. Let's adapt to it and we will all be happier.

You might be; I will be sad. It comes for a price, and with little benefit. Disk space is cheaper than my time to fight build processes.

And btw, there is no need to install the msvcr8.dll. We can distribute them as a private assembly. then they (and the manifest) exist in the same directory as python2x.dll.

Yes, but then python2x.dll goes into system32, and so will msvcr8.dll, no?

...

Not sure whether anything really is needed. Python works fine on Vista. If you are an administrator. A limited user will have problems installing it and then running it.

Is there a bug report for that?

...

...

1) supplying python.dll as a Side By Side assembly What would that improve? Well, it should reduce dll-hell problems of applications that ship with python2x.dll. You ship with and link to your own and tested dll. We have some concerns here, for example, now that we are moving away from embedding python in our blue.dll and using python25.dll directly, that this exposes a vulnerability to the integrity of the software.

Why should there be versioning problems with python25.dll? Are there any past issues with incompatibilities with any python2x.dll release?

...

...

2) Changing python install locations To conform with Windows rules and get a "Vista approved" logo. Install in the ProgramFiles folder.

Only over my dead body. *This* is silly.

Just as C does. Ah, and this also means that we could install both 32 bit and 64 bit versions, another plus.

What about the registry?

Interesting. We are definitely interested in that. You see, Someone installs a game or accounting software using vista. He then runs as a limited user. Python insists on saving its .pyc files in the installation folder, but this is not something that is permitted on Vista.

But that's not a problem, is it? Writing silently "fails", i.e. it just won't save the pyc files. Happens all the time on Unix.

...

Sure, and have they reported problems with Python on Vista (problems specific to Vista?) Certainly. We are working on them, of course.

But, of course, they have not been reported. Regards, Martin

-----Original Message----- From: "Martin v. Löwis" [mailto:martin@v.loewis.de]

That couldn't work for me. I try avoid building on a network drive, and with local drives, I just can't have a Windows build and a Linux build on the same checkout - they live on separate file systems, after all (Linux on ext3, Windows on NTFS, with multi-boot switching between them). Very well, leaving linux aside, I don't see why this: /win32mount/trunk/PCbuild/ /x64mount/trunk/PCbuild/

Is any different from /winmount/trunk/PCBuild/win32 /winmount/trunk/PCBuild/x64 I don't understand this extraordinary reluctance to add a single extra directory. The windows build process is different from any other build process, so even If all the other platforms live one directory higher, why must windows?

I don't *use* them simultaneously, of course - I cannot work on two architectures simultaneously, anyway. I do so on a daily basis. I designed PCBuild8 to be easy for interactive work using VisualStudio, using property sheets and such to group common settings for easy editing. During the course of my work, I will edit a file (which is checked out from Perforce), compile debug for two platforms, test, and repeat.

...

I say let's just admit that tools can compile for more than one target. Let's adapt to it and we will all be happier.

You might be; I will be sad. It comes for a price,

...

And btw, there is no need to install the msvcr8.dll. We can distribute them as a private assembly. then they (and the manifest) exist in the same directory as python2x.dll.

Yes, but then python2x.dll goes into system32, and so will msvcr8.dll, no? Yes, that is correct. Well, there is a CRT .exe redist if you want to deploy

I well understand the benefits, I use it all the time, but the price still eludes me. how can a different name for the output folder for a different platform be such a big problem? this into the SxS cache, it just has to be run as part of the install process. But that may or may not be problematic, I don't know.

...

...

Not sure whether anything really is needed. Python works fine on Vista. If you are an administrator. A limited user will have problems installing it and then running it.

Is there a bug report for that?

I don't know. At any rate, I think any vista issues is a completely separate thing, something that needs to be handled as a whole, rather than responding to a particular problem reported in a bug report.

...

...

...

1) supplying python.dll as a Side By Side assembly What would that improve? Well, it should reduce dll-hell problems of applications that ship with python2x.dll. You ship with and link to your own and tested dll. We have some concerns here, for example, now that we are moving away from embedding python in our blue.dll and using python25.dll directly, that this exposes a vulnerability to the integrity of the software.

Why should there be versioning problems with python25.dll? Are there any past issues with incompatibilities with any python2x.dll release?

Someone could replace the python25.dll that we ship with their own patched version, thereby gaining backdoor access to the software. The way windows searches for old style dlls makes this easy. Using the SxS signed loading scheme, you can protect yourself up to a point from such attacks. Of course, this doesn't have to be a problem for vanilla python, we can do this on our own for the patched python25 that we employ, but it still might be something others could find useful.

...

Install in the ProgramFiles folder.

Only over my dead body. *This* is silly. Bill doesn't think so. And he gets to decide. I mean we do want to play nice, don't we? Nothing installs itself in the root anymore, not since windows 3.1

...

Just as C does. Ah, and this also means that we could install both 32 bit and 64 bit versions, another plus.

What about the registry?

I don't know about the registry, what is it used for? 64 bit windows already ships with dual versions of some apps, notably explorer.exe so that shouldn't be a big problem.

...

Interesting. We are definitely interested in that. You see, Someone installs a game or accounting software using vista. He then runs as a limited user. Python insists on saving its .pyc files in the installation folder, but this is not something that is permitted on Vista.

But that's not a problem, is it? Writing silently "fails", i.e. it just won't save the pyc files. Happens all the time on Unix.

It may not silently fail, depending on your user status. An admin might get a confirmation window, for example.

...

...

Sure, and have they reported problems with Python on Vista (problems specific to Vista?) Certainly. We are working on them, of course.

But, of course, they have not been reported.

These are not python errors as such, but rather EVE errors. We ship the .py files precompiled and therefore avoid the aforementioned problems. But we have had to move all sorts of temporary files out of "program files" and into "documents and settings/user/local settings/Application Data/CCP/Eve Kristjan

Very well, leaving linux aside, I don't see why this: /win32mount/trunk/PCbuild/ /x64mount/trunk/PCbuild/

Is any different from /winmount/trunk/PCBuild/win32 /winmount/trunk/PCBuild/x64

I don't understand this extraordinary reluctance to add a single extra directory. The windows build process is different from any other build process, so even If all the other platforms live one directory higher, why must windows?

It doesn't need to, and reluctance is not wrt. to the proposed new layout, but wrt. changing the current one. Tons of infrastructure depends on the files having exactly the names that they have now, and being located in exactly the locations where they are currently located. Any change to that, whatever minor, will cause problems to some people. So for the change to be made, the advantages must clearly outweigh the incompatibility of the change in the first place.

...

...

I say let's just admit that tools can compile for more than one target. Let's adapt to it and we will all be happier. You might be; I will be sad. It comes for a price, I well understand the benefits, I use it all the time, but the price still eludes me. how can a different name for the output folder for a different platform be such a big problem?

When running Python now, I type (after having changed to the source directory in the cmd.exe window) PCb<tab>pyt<tab><tab> or some such. To navigate to a subdirectory, I need many more keystrokes. I find it very painful to invoke python.exe from the PCbuild8 directory. I don't want that pain to be the default.

Yes, that is correct. Well, there is a CRT .exe redist if you want to deploy this into the SxS cache, it just has to be run as part of the install process. But that may or may not be problematic, I don't know.

Microsoft recommends to use the merge module (.msm), and I think this is what should be done (if feasible).

...

Why should there be versioning problems with python25.dll? Are there any past issues with incompatibilities with any python2x.dll release? Someone could replace the python25.dll that we ship with their own patched version, thereby gaining backdoor access to the software. The way windows searches for old style dlls makes this easy. Using the SxS signed loading scheme, you can protect yourself up to a point from such attacks. Of course, this doesn't have to be a problem for vanilla python, we can do this on our own for the patched python25 that we employ, but it still might be something others could find useful.

I personally think that if hostile users can replace DLLs on your system, you have bigger problems than SxS installation of pythhonxy.dll, but perhaps that's just me.

...

...

Install in the ProgramFiles folder. Only over my dead body. *This* is silly. Bill doesn't think so. And he gets to decide.

He can decide not to give Python the "Vista ready" logo. If so, I don't want it. He cannot decide to make the Python installer to install into a directory with a space in its name by default.

I mean we do want to play nice, don't we?

Nice to users of Python, sure. I would not have said a word if the standard directory would have been, say "\usr\bin". However, they happened to chose "Program Files", making it language dependent, and putting a space in the name. That space has caused numerous problems to Python scripts, and I expect changing the default would cause a lot of problems to end users.

...

What about the registry? I don't know about the registry, what is it used for?

For two things, with different importance to different users: 1. File extensions are registered there, e.g. .py and .pyc. With two binaries installed, the will stomp over each other's file associations; only one of them can win. 2. Python installs keys under HL{LM|CU}\Software\Python\PythonCore\<version>, namely InstallPath InstallGroup PythonPath Documentation Modules For some of these, add-on libraries and applications may modify these keys, and the interpreter will pick up the changes. Again, there can be only one installation on the system "owning" these settings; two simultaneous installations will stomp on each other's settings.

64 bit windows already ships with dual versions of some apps, notably explorer.exe so that shouldn't be a big problem.

The two versions of MSIE actually *are* a big problem, that's why MS only runs the 32-bit IE, even on Win64 (otherwise, ActiveX controls downloaded from the net wouldn't work). Also, while they are both shipped, you can't the two versions of explorer.exe simultaneously (without trickery), so its far from simple.

...

But that's not a problem, is it? Writing silently "fails", i.e. it just won't save the pyc files. Happens all the time on Unix. It may not silently fail, depending on your user status. An admin might get a confirmation window, for example.

Can you describe the precise scenario which makes that happen? To my knowledge, Vista will *not* open a confirmation window when Python attempts to write a .pyc file. Regards, Martin

- Run the appropriate environment setup for the correct compiler. E.g., for the Platform SDK AMD64 compiler and with the current Platform SDK this is:

C:\Program Files\Microsoft Platform SDK\SetEnv.Cmd /X64 /RETAIL

- Run the solution file with "devenv.com" (IIRC, devenv.exe doesn't take command-line args) and be sure to pass ing "/useenv" to pick up the environment changes. (*)

set DEVENV_COM=path/to/devenv.com %DEVENV_COM% PCbuild\pcbuild.sln /useenv /build ReleaseAMD64

Yes, that should work equally fine.

I haven't looked into what vsextcomp does, so apologies if this is ignorant.

It spares you having to setup the environment; it provides a cl.exe wrapper that locates the SDK from the registry, and then invokes the cl.exe in the SDK if necessary. As a consequence, you can still just double-click the solution file, without having to run devenv.exe/com manually. Regards, Martin

Martin v. Löwis wrote:

...

I use this patch in ActivePython to get distutils to find the correct PCbuild dir (see attached).

Would you like to commit this to 2.6? (or perhaps 2.5 even?)

Sure, if others think it is a good thing. Will do tomorrow unless I hear a -1 before then. Trent -- Trent Mick trentm at activestate.com

I'm not quite a '-1', but am a little confused about where this would leave us. To some extent, this would formalize PCBuild8 and VC6 directories. External tools would then slowly start growing support for these additional directories and the previous benefits of "PCBuild is the canonical location" appear to vanish. Further, I expect that such a patch would confuse any attempts to manually copy from PCBuild8 into PCBuild, for example (ie, some tools knowing about PCBuild8 while others assume PCBuild is likely to get confusing.)

Trent: I assume you use the same source tree for multiple platforms and compilers, meaning that changing these "optional" build processes to copy from PCBuild8/VC6 into PCBuild would cause pain? If not, do you think that would be a reasonable solution?

Changing to have bits always in PCbuild would work for me -- i.e. I *don't* build for multiple compilers/platforms in the same tree. Perhaps that is a better solution -- in the long run, anyway. Having the "bits" always in one dir for whatever the configuration is more akin to the Unix-y configure/make system. Is this something that could work for Python 2.5? Or just 2.6? Long term/aside: Moving to a configure/make build system on Windows, as you proposed in your first email, would be interesting. With MSYS though, not cygwin (a la bsmedberg's new MozillaBuild stuff). I just wish there were an autoconf alternative that wasn't as painful as autoconf. I have a few attempts for my purposes that are written in Python (an obvious bootstrapping problem for building Python itself :). Trent -- Trent Mick trentm at activestate.com

-----Original Message----- From: "Martin v. Löwis" [mailto:martin@v.loewis.de]

It doesn't need to, and reluctance is not wrt. to the proposed new layout, but wrt. changing the current one. Tons of infrastructure depends on the files having exactly the names that they have now, and being located in exactly the locations where they are currently located. Any change to that, whatever minor, will cause problems to some people.

Just to be absolutely clear: You are talking about the build environment, right? Because I am not proposing to change any layout of the installed Python (wherever that may be :) I am baffled about why the build environment's layout matters, but once an .msi install can place the binaries in any old place it wants. The build structure doesn't have to reflect the final installed structure at all. Kristján

-----Original Message-----

I personally think that if hostile users can replace DLLs on your system, you have bigger problems than SxS installation of pythhonxy.dll, but perhaps that's just me. An end user application on an end-user's machine is always voulnerable to reverse engineering. But it helps to make it more difficult. The old-style dll loader is a particular vulnerability which makes it easy to patch into an application at load time.

...

...

What about the registry? I don't know about the registry, what is it used for?

For two things, with different importance to different users: 1. File extensions are registered there, e.g. .py and .pyc. With two binaries installed, the will stomp over each other's file associations; only one of them can win. Sure. No argument about this. But as with the explorer and other apps, it is perfectly possible to manually start one or the other, autoclicking on .py files isn't the only option.

2. Python installs keys under HL{LM|CU}\Software\Python\PythonCore\<version>, namely InstallPath InstallGroup PythonPath Documentation Modules

Funnily enough, Bill has thought of this too. See http://support.microsoft.com/kb/305097/ for info. Co-existence of 32 and 64 bit apps is supported.

The two versions of MSIE actually *are* a big problem, that's why MS only runs the 32-bit IE, even on Win64 (otherwise, ActiveX controls downloaded from the net wouldn't work).

Also, while they are both shipped, you can't the two versions of explorer.exe simultaneously (without trickery), so its far from simple.

The two versions aren't the problem, it is the backward support for 32 bit active thingies that are, as you point out. There is confusion here: internet explorer shipped in both versions. The 32 bit version war default for the above reason. But explorer.exe (which I was talking about) also had two versions. The 64 bit version ran by default. You may recall that before tortoise shipped a 64 bit version, one had to kill explorer.exe and restart it (explorer32.exe IIRC) to get tortoise to work. Supporting both kinds (country and western) on the same machine might be helpful to people for this very reason. A lot of legacy modules are only avaible in 32 bit mode. But people may want to do contemporary development using the new 64 bit mode. Cheers, Kristján

Development tools used on windows already have to cope with this. Spaces are not going away, so why not bite the bullet and deal with them? Moving forward sometimes means crossing rivers.

But in a safe path, step by step. People continue to report problems with spaces in file names, even though many of them have been solved also.

As for Vista issues, I'll gather more data before making any more claims, but I think that it is important that we play by the rules here.

I completely disagree. It is important that it "works", not that we play by the rules.

Just imagine the a school teacher who in good faith wants to introduce his pupils to the wonderful programming language of Python, but when he installs it, all kinds of scary looking warnings drive him off. Vista is, like it or not, going to be very prevalent. If we want python to be easily accessible to the masses, we mustn't take an elitist attitude or else risk scaring people off.

I'm completely in favor of fixing actual bugs. However, I'm not aware of any (related to Vista). That it is not logo compliant is *not* a bug. Python hasn't been logo compliant for more than a decade now (the "install to Program Files" is not a new requirement, but existed since Win95). Regards, Martin

From: Jamie Kirkpatrick [mailto:jkp@kirkconsulting.co.uk] Sent: Wednesday, 23 May 2007 5:16 AM

I have a set of extensions that use SWIG to wrap my own C++ library. This library, on a day-to-day basis is built against VS8 since the rest of our product suite is. Right now I have no way to work with this code using VS8 since the standard distribution is built against VS7 which uses a different CRT. This is an absolute nightmare in practice since I currently have to maintain VS7 projects in parallel with the standard VS8 ones simply so that I can run and test my python code.

I've downloaded the Python source and had a look at building up my own distributions for each case (ideally there would be an easy way to separate out Release / Debug

VS8 / VS7 variants, and I guess potentially for those cross-compiling we'd need to go a step further and do this per arch as well. Anyway, this isn't how it works at

If you are brave and willing to ensure your module doesn't voilate certain constraints (such as never passing a CRT 'concept' - such as a file handle or memory block to be free'd) across mismatched CRT boundaries, you may find that you can happily load your VS8 built pronect with VS7 - but yes, your general point is valid but beyond the scope of this discussion. A separate discussion on making Python "crt agnostic" is almost certainly worthwhile though, but not directly related to this current discussion. products as well as the the moment, but I'm

still searching for a way to be able to work on the python code in VS8. Building using the current projects I seem to get everything in the PCBuild8 / PCBuild dirs. How can I work with what is build?

Is there a shell script to build a final distribution tree? If not, is

way to build an MSI similar to the one found on the Python.org site for

This is *exactly* the point of this thread, and what we are trying to resolve. In the short term, we have agreed a change to PCBuild8\build.bat that copies the build files into PCBuild is a solution that should "work", where "work" is defined as "allow a source tree built with VS8 to operate in the same way, from the POV of building extensions, as one built with VS8." My primary issue with this is solved by the change to the .bat file, but we welcome all feedback from people who believe this is not ideal. I've agreement from Kristjan on the specific change to that .bat file, I'm just yet to check it in (but it literally just copies everything from the PVBuild8 target dir into the PCBuild dir after checking the expected dirs do indeed exist) there a simple the official

releases but using the PCBuild8 stuff?

I believe not. In most cases, people who build from source on Windows will run directly from that source tree, rather than attempting the intermediate step of creating a .msi and installing it.

If not how do you recommend getting myself to a state where I have at least a feature complete distribution build against VS8? I'm happy with a one time build that I can just install into my source tree and upload to the SCM.

I'd suggest that once I check the .bat change in, you build the PCBuild8 directory via that .bat file, then continue to use the 'PCBuild' directory as it it were a VC7 build. Cheers, Mark

Martin v. Löwis wrote:

...

I have a set of extensions that use SWIG to wrap my own C++ library. This library, on a day-to-day basis is built against VS8 since the rest of our product suite is. Right now I have no way to work with this code using VS8 since the standard distribution is built against VS7 which uses a different CRT. This is an absolute nightmare in practice since I currently have to maintain VS7 projects in parallel with the standard VS8 ones simply so that I can run and test my python code.

If you know well enough what you are doing, and avoid using unsupported cases, you *can* mix different CRTs.

I can attest to this - I have SWIG-wrapped extensions built with VC6 running quite happily against the official VS7 binaries for Python 2.4. Moving from Python 2.2 to Python 2.4 was a simple matter of recompiling and relinking the modules. The important thing was to make sure to never pass memory ownership or standard lib data structures across the boundary. I haven't actually found this to be all that difficult in practice, as I am typically either copying data from standard library data structures into native Python data structures (e.g. between std::string and PyString) or else merely accessing the Python wrappers around my own C++ classes. In both cases memory ownership remains entirely within the extension module, and all interaction occurs through the Python C API, and never indirectly through the CRT. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

One feature that is easily addable and will certainly make installing python on vista nicer, is to add authenticode signing to the install.

This I question very much. I experimented with authenticode before 2.4, and found it an unacceptable experience. When the MSI file starts running, installer needs to verify the signature, for which it needs to compute a hash of the entire file. For the Python MSI, this takes many seconds on a slower Pentium 4 machine. During that time, there is no visual feedback, so users are uncertain whether they have actually invoked the MSI file at all.

Currently the user is faced with a very nasty and off-putting message about an unidentified program requesting access to his computer.

Certainly. However, telling them that they have to wait just so that Windows finds out what they know already (that this is the MSI file from the Python Software Foundation, or from Martin v. Löwis) is even more nasty. Regards, Martin

Hi,

...

One feature that is easily addable and will certainly make installing python on vista nicer, is to add authenticode signing to the install.

I'm +1 on authenticode.

This I question very much. I experimented with authenticode before 2.4, and found it an unacceptable experience. When the MSI file starts running, installer needs to verify the signature, for which it needs to compute a hash of the entire file. For the Python MSI, this takes many seconds on a slower Pentium 4 machine. During that time, there is no visual feedback, so users are uncertain whether they have actually invoked the MSI file at all.

...

Currently the user is faced with a very nasty and off-putting message about an unidentified program requesting access to his computer.

Certainly. However, telling them that they have to wait just so that Windows finds out what they know already (that this is the MSI file from the Python Software Foundation, or from Martin v. Löwis) is even more nasty.

Educated, adult developers with good internet connections may know that, but all users? What about software on a CD or a memory stick? Also, software sites/mirrors have been compromised in the past, and they are a sweet target. I haven't looked at authenticode, but I guess it's a cryptographical signature. That defaults to a good thing. That the verification takes time is unfortunate, but unavoidable. That the user interface sucks (no feedback) is a bug. You will have the say whether Python uses authenticode, but I'm not convinced by your arguments. - Lars

Dear Martin,

...

Educated, adult developers with good internet connections may know that, but all users? What about software on a CD or a memory stick?

Also, I believe users *still* get a confirmation window, just the message changes from "we don't know who wrote this software" to "we know PSF wrote it - do you trust them?"

Ugh. Still better than a warning.

So, "all users" aren't any better off with authenticode.

...

I haven't looked at authenticode, but I guess it's a cryptographical signature.

Correct.

...

That defaults to a good thing.

That's a very common pitfall, and untrue. People are talked into believing that signed software is "more trustworthy" than unsigned software. This is absolutely not the case. The signed software may just as well contain malware. The only difference is that you can go after the author - provided you can get hold of him, and provided you can prove (in court) that it was actual that software that caused the damage. Depending on the malware, you may not even know that damage was made, e.g. if it was signed spyware.

Yes, I am aware of that. But the signature makes a man-in-the-middle attack harder.

So code-signing can very realistically give a false sense of security. This is *not* a good thing.

...

You will have the say whether Python uses authenticode, but I'm not convinced by your arguments.

I think I'll have to produce a signed version of the 2.5.1 installer, so that people can see for themselves.

That is a friendly idea. Thank you. - Lars

At 12:57 PM 5/30/2007 +0200, henk-jan ebbers wrote:

I have 2 questions about using setuptools for a windows installer:

1. I want to make a executable-windows-installer with setuptools (bdist_wininst) . in setup.py I place a dependency: install_requires = ["TurboGears >= 1.0.1",], installation is not zip-safe: zip_safe=False, The target-machine (where I do the install) has easy_install already installed. Am I right that when I install this executable-windows-installer the dependency is not automatically installed?

That's correct.

Or is there a way to do this with setuptools that I have overlooked?

2. in distritools it is possible to use a postinstallation script (*--install-script *option). (which I want to use shortcuts in menu's). This is not possible in setuptools?

It's possible with bdist_wininst, but if a user installs the .exe using easy_install, the postinstall script will be ignored.

At 06:03 PM 5/30/2007 +0200, henk-jan ebbers wrote:

So: either a user uses the executable-windows-installer (with postinstallation script, but dependencies are not resolved), or a user uses easy_install <egg> (without postinstallation script, but dependencies are resolved)

Is it possible to place something like 'easy_install <dependecies>' in the postinstallation script?

Sure, although of course those dependencies won't have *their* post-install scripts run. If you do this, you probably want to have the postinstall script register the files installed. easy_install's --record option lets you write the installed files and directories to a text file, so you could read that and record the results. That way, if the .exe is uninstalled, the other files will go along. The downside to this is that uninstalling the .exe will uninstall dependencies that might actually be depended on by other packages that are installed later -- IOW, a total mess. So, I'm not sure it's a good idea. No, scratch that, I'm pretty sure it's NOT a good idea. It might be better to use bdist_msi instead, if that has a way of handling dependencies. (I'm not sure if it does.)

...

...

Educated, adult developers with good internet connections may know that, but all users? What about software on a CD or a memory stick?

Also, I believe users *still* get a confirmation window, just the message changes from "we don't know who wrote this software" to "we know PSF wrote it - do you trust them?"

Ugh. Still better than a warning.

It's still a warning.

...

That's a very common pitfall, and untrue. People are talked into believing that signed software is "more trustworthy" than unsigned software. This is absolutely not the case. The signed software may just as well contain malware. The only difference is that you can go after the author - provided you can get hold of him, and provided you can prove (in court) that it was actual that software that caused the damage. Depending on the malware, you may not even know that damage was made, e.g. if it was signed spyware.

Yes, I am aware of that. But the signature makes a man-in-the-middle attack harder.

Sure. However, I think that this protection against an unlikely scenario cannot outweigh the main problem of code signing: that people get a false sense of security. And trust (sic) me: they do. Regards, Martin

Us trying to lecture MS on software security is pointless.

I didn't try to lecture MS. I explained that to Lars Immisch, who essentially said that authenticode is a good thing because it is based on certificates. Regards, Martin

I'm wondering if anyone has any comment on this issue? Its currently impossible to use distutils as documented to build x64 extensions, either natively or cross-compiled using the trunk and while I'm keen to help fix this, I'd like agreement on the direction. Can I assume silence means general agreement on the compromise proposal I outlined? Thanks, Mark

-----Original Message----- From: python-dev-bounces+mhammond=keypoint.com.au@python.org [mailto:python-dev-bounces+mhammond=keypoint.com.au@python.org] On Behalf Of Mark Hammond Sent: Tuesday, 22 January 2008 9:06 PM To: '"Martin v. Löwis"' Cc: distutils-sig@python.org; python-dev@python.org Subject: Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows

Hi Martin,

Way back on Monday, 21 May 2007, you wrote:

...

This is an issue to be discussed for Python 2.6. I'm personally hesitant to have the "official" build infrastructure deviate from the layout that has been in-use for so many years, as a lot of things depend on it.

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

...

* Re the x64 directory used by the PCBuild8 process. IMO, it makes sense to generate x64 binaries to their own directory - my expectation is that cross-compiling between platforms is a reasonable use-case, and we should support multiple achitectures for the same compiler version.

See above; I disagree.

[For additional context; the question was regarding where the output binaries were created for each platform, and specifically if x64 build should use something like 'PCBuild/x64']

I'm bringing this topic up again as I noticed the AMD64 builds for Python 2.6 create their output in the PCBuild/x64 directory, not directly into the PCBuild directory. When I raised this with Christian, he also expressed a desire to be able to cross-compile in the same directory structure and was unaware of this discussion (but I made him aware of it :)

You made excellent points about how tools currently recognize the PCBuild directory, and we can't break them, and I agree. I'd like to propose a compromise that might be able to keep everyone happy.

The main problem I see with all platforms using 'PCBuild' is that in a cross-compilation scenario, it is impossible for the distutils to determine the location of the correct Python libraries to link with (stuff in its own PYTHONHOME is no good; it's for the wrong platform). Obviously, we can change the distutils so that the location of the correct libraries can be specified, but that implies all other build systems that currently assume PCBuild must also change to work in a cross-compilation scenario. While those external tools *will* work today in a native build on x64, eventually they may need to be upgraded to deal with cross-compilation - and this means that all such tools will also be unable to automatically determine the location of the libraries. They will all need to take the library dir as a user-specified option, which seems a pain (eg, buildbots would seem to need site-specific configuration information to make this work). If eventually all such tools are likely to upgrade, it would be ideal if we can offer them a way to upgrade so the correct libraries can be determined automatically, as they can now for native builds.

My compromise proposal is this: Each platform builds in its own directory (ie, PCBuild/x86_64, PCBuild/x86). Every single build configuration has a post-build step that copies the result of the build to the PCBuild directory. We then add an option to the distutils so that a cross- compile platform can be specified and when it is, to use 'PCBuild/{platform}" instead of PCBuild, and we encourage other tools to use the same directory should they want to support "configure-less" cross-compilation (if distutils on the trunk is not still trying to maintain b/w compat, it should just *always* look in PCBuild/{platform}, and I'd suggest py3k not bother with PCBuild at all; build systems will be touched to upgrade to py3k, so that change isn't painful. But I digress :)

The main advantage of the compromise is that it allows for the status quo to remain in place - just continue to use separate source trees for each platform, and only ever build a single platform in each tree, and tools are free to have ways of specifying which directory should be used. The official build process need not change. However, it also supports a way to do cross-compilation in a way that build tools can *automatically* locate the correct platform's libraries, and this will be particularly useful for extension authors.

Would something like that be acceptable?

Thanks,

Mark

_______________________________________________ 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/mhammond%40keypoint.com.au