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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Mark Hammond > Sent: Tuesday, 22 January 2008 9:06 PM > To: '"Martin v. Löwis"' > Cc: [EMAIL PROTECTED]; 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 _______________________________________________ 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
