[Python-Dev] Adventures with x64, VS7 and VS8 on Windows

[Gregory P. Smith]

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)

On Wed, Jan 30, 2008 at 11:25 PM, Mark Hammond <mhammond at skippinet.com.au>
wrote:

> 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 at python.org
> > [mailto:python-dev-bounces+mhammond=keypoint.com.au at python.org] On
> > Behalf Of Mark Hammond
> > Sent: Tuesday, 22 January 2008 9:06 PM
> > To: '"Martin v. Löwis"'
> > Cc: distutils-sig at python.org; python-dev at 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 at 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 at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080321/ce86f0d0/attachment.htm