I'm following up on this thread without checking if there were other following negating a need to respond... If so, ignore as needed.<br><br>+1 from me. Always build on windows into an architecture specific PCBuild/XXX directory. A bonus if the directory name matches the return value of platform.machine() but I don't care too much about that part. (that'd mean 'i686' and 'x86_64' and who knows what for Itanic users)<br>
<br><div class="gmail_quote">On Wed, Jan 30, 2008 at 11:25 PM, Mark Hammond <<a href="mailto:mhammond@skippinet.com.au">mhammond@skippinet.com.au</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm wondering if anyone has any comment on this issue? Its currently<br>
impossible to use distutils as documented to build x64 extensions, either<br>
natively or cross-compiled using the trunk and while I'm keen to help fix<br>
this, I'd like agreement on the direction.<br>
<br>
Can I assume silence means general agreement on the compromise proposal I<br>
outlined?<br>
<br>
Thanks,<br>
<br>
Mark<br>
<div><div></div><div class="Wj3C7c"><br>
> -----Original Message-----<br>
> From: python-dev-bounces+mhammond=<a href="mailto:keypoint.com.au@python.org">keypoint.com.au@python.org</a><br>
> [mailto:<a href="mailto:python-dev-bounces+mhammond=keypoint.com.au@python.org">python-dev-bounces+mhammond=keypoint.com.au@python.org</a>] On<br>
> Behalf Of Mark Hammond<br>
> Sent: Tuesday, 22 January 2008 9:06 PM<br>
> To: '"Martin v. Löwis"'<br>
> Cc: <a href="mailto:distutils-sig@python.org">distutils-sig@python.org</a>; <a href="mailto:python-dev@python.org">python-dev@python.org</a><br>
> Subject: Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows<br>
><br>
> Hi Martin,<br>
><br>
> Way back on Monday, 21 May 2007, you wrote:<br>
><br>
> > This is an issue to be discussed for Python 2.6. I'm personally<br>
> > hesitant to have the "official" build infrastructure deviate<br>
> > from the layout that has been in-use for so many years, as a lot<br>
> > of things depend on it.<br>
> ><br>
> > I don't find the need to have separate object directories convincing:<br>
> > For building the Win32/Win64 binaries, I have separate checkouts<br>
> > *anyway*, since all the add-on libraries would have to support<br>
> > multi-arch builds, but I think they don't.<br>
> ...<br>
> > > * Re the x64 directory used by the PCBuild8 process. IMO, it makes<br>
> > > sense to generate x64 binaries to their own directory - my<br>
> expectation<br>
> > > is that cross-compiling between platforms is a reasonable use-case,<br>
> > > and we should support multiple achitectures for the same compiler<br>
> > > version.<br>
> ><br>
> > See above; I disagree.<br>
><br>
> [For additional context; the question was regarding where the output<br>
> binaries were created for each platform, and specifically if x64 build<br>
> should use something like 'PCBuild/x64']<br>
><br>
> I'm bringing this topic up again as I noticed the AMD64 builds for<br>
> Python<br>
> 2.6 create their output in the PCBuild/x64 directory, not directly into<br>
> the<br>
> PCBuild directory. When I raised this with Christian, he also<br>
> expressed a<br>
> desire to be able to cross-compile in the same directory structure and<br>
> was<br>
> unaware of this discussion (but I made him aware of it :)<br>
><br>
> You made excellent points about how tools currently recognize the<br>
> PCBuild<br>
> directory, and we can't break them, and I agree. I'd like to propose a<br>
> compromise that might be able to keep everyone happy.<br>
><br>
> The main problem I see with all platforms using 'PCBuild' is that in a<br>
> cross-compilation scenario, it is impossible for the distutils to<br>
> determine<br>
> the location of the correct Python libraries to link with (stuff in its<br>
> own<br>
> PYTHONHOME is no good; it's for the wrong platform). Obviously, we can<br>
> change the distutils so that the location of the correct libraries can<br>
> be<br>
> specified, but that implies all other build systems that currently<br>
> assume<br>
> PCBuild must also change to work in a cross-compilation scenario.<br>
> While<br>
> those external tools *will* work today in a native build on x64,<br>
> eventually<br>
> they may need to be upgraded to deal with cross-compilation - and this<br>
> means<br>
> that all such tools will also be unable to automatically determine the<br>
> location of the libraries. They will all need to take the library dir<br>
> as a<br>
> user-specified option, which seems a pain (eg, buildbots would seem to<br>
> need<br>
> site-specific configuration information to make this work). If<br>
> eventually<br>
> all such tools are likely to upgrade, it would be ideal if we can offer<br>
> them<br>
> a way to upgrade so the correct libraries can be determined<br>
> automatically,<br>
> as they can now for native builds.<br>
><br>
> My compromise proposal is this: Each platform builds in its own<br>
> directory<br>
> (ie, PCBuild/x86_64, PCBuild/x86). Every single build configuration<br>
> has a<br>
> post-build step that copies the result of the build to the PCBuild<br>
> directory. We then add an option to the distutils so that a cross-<br>
> compile<br>
> platform can be specified and when it is, to use 'PCBuild/{platform}"<br>
> instead of PCBuild, and we encourage other tools to use the same<br>
> directory<br>
> should they want to support "configure-less" cross-compilation (if<br>
> distutils<br>
> on the trunk is not still trying to maintain b/w compat, it should just<br>
> *always* look in PCBuild/{platform}, and I'd suggest py3k not bother<br>
> with<br>
> PCBuild at all; build systems will be touched to upgrade to py3k, so<br>
> that<br>
> change isn't painful. But I digress :)<br>
><br>
> The main advantage of the compromise is that it allows for the status<br>
> quo to<br>
> remain in place - just continue to use separate source trees for each<br>
> platform, and only ever build a single platform in each tree, and tools<br>
> are<br>
> free to have ways of specifying which directory should be used. The<br>
> official build process need not change. However, it also supports a<br>
> way to<br>
> do cross-compilation in a way that build tools can *automatically*<br>
> locate<br>
> the correct platform's libraries, and this will be particularly useful<br>
> for<br>
> extension authors.<br>
><br>
> Would something like that be acceptable?<br>
><br>
> Thanks,<br>
><br>
> Mark<br>
><br>
><br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="http://mail.python.org/mailman/options/python-" target="_blank">http://mail.python.org/mailman/options/python-</a><br>
</div></div>> dev/mhammond%40keypoint.com.au<br>
<div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/greg%40krypto.org" target="_blank">http://mail.python.org/mailman/options/python-dev/greg%40krypto.org</a><br>
</div></div></blockquote></div><br>