I'm following up on this thread without checking if there were other following negating a need to respond... If so, ignore as needed.
+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)
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
> dev/mhammond%40keypoint.com.au
> -----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-
_______________________________________________
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/greg%40krypto.org