This patch adds a new configure argument on OSX:
--with-universal-archs=[32-bit|64-bit|all]
When used with the --enable-universalsdk option this controls which
CPU architectures are includes in the framework. The default is 32-bit,
meaning i386 and ppc. The most useful alternative is 'all', which includes
all 4 CPU architectures supported by MacOS X (i386, ppc, x86_64 and ppc64).
This includes limited support for the Carbon bindings in 64-bit mode as well,
limited because (a) I haven't done extensive testing and (b) a large portion
of the Carbon API's aren't available in 64-bit mode anyway.
I've also duplicated a feature of Apple's build of python: setting the
environment variable 'ARCHFLAGS' controls the '-arch' flags used for building
extensions using distutils.
Updated the documentation to use the new name.
Revert addition of the stub entry for the old name.
Georg, I am reverting your changes since this commit should propagate
to py3k.
Allow multiple repositories in .pypirc; see http://wiki.python.org/moin/EnhancedPyPI
for discussion.
The patch is slightly revised from Tarek's last patch: I've simplified
the PyPIRCCommand.finalize_options() method to not look at sys.argv.
Tests still pass.
directory that is not the source directory (ie, one created using
'/path/to/source/configure'.) Leaves this test very slightly degraded in
that particular case, compared to the build-in-sourcedir case, but that case
isn't a particularly strong test either: neither test the actual path that
will be used after installing. There isn't a particularly good way to test
this, and a poor test beats a failing test.
directory to the directory in which the setup.py script lived (which made
__file__ wrong)
fixed, with test that the script is run in the current directory of the caller
callable() from copy_reg.py, so the interpreter now starts up
without warnings when '-3' is given. More work like this needs to
be done in the rest of the stdlib.
The new msvc9compiler module supports VS 2005 and VS 2008. I've also fixed build_ext to support PCbuild8 and PCbuild9 and backported my fix for xxmodule.c from py3k. The old code msvccompiler is still in place in case somebody likes to build an extension with VS 2003 or earlier.
I've also updated the cygwin compiler module for VS 2005 and VS 2008. It works with VS 2005 but I'm unable to test it with VS 2008. We have to wait for a new version of cygwin.
As discussed on distutils-sig: Allows the generated installer name on
64bit Windows platforms to be different than the name generated for
32bit Windows platforms.
As discussed on distutils-sig: Allows the generated installer name on
64bit Windows platforms to be different than the name generated for
32bit Windows platforms.
even if package_dir is empty.
This needs to be backported. I'm too tired tonight. It would be great
if someone backports this if the buildbots are ok with it. Otherwise,
I will try to get to it tomorrow.
If MSVCCompiler.initialize() was called multiple times, the path
would get duplicated. On Windows, this is a problem because the
path is limited to 4k. There's no benefit in adding a path multiple
times, so prevent that from occuring. We also normalize the path
before checking for duplicates so things like /a and /a/ won't both
be stored.
Will backport.
installed to build extensions. This patch makes distutils emit a warning when
the compiler should use an SDK but that SDK is not installed, hopefully reducing
some confusion.
universal build of python on OSX 10.3 to ensure that those flags can be used
to compile code (the universal build uses compiler flags that aren't supported
on 10.3). This patches gives the same treatment to CFLAGS, PY_CFLAGS and
BLDSHARED.
This patchs makes it possible to create a universal build on OSX 10.4 and use
the result to build extensions on 10.3. It also makes it possible to override
the '-arch' and '-isysroot' compiler arguments for specific extensions.
configure time. The current check is too strict and doesn't allow building
extensions that can only run on newer versions of the OS than the version
python was build for, that is python build for 10.3 or later and an extension
for 10.4. This patch relaxes this check.
This turned out to be a reimplementation of patch 1193190.
/path/to/uninstalled/python setup.py build_ext
now failed with pyconfig.h not found. Prior to r45232
the above command did not look for pyconfig.h, but the
bug is really in the look-up code: expecting to find it
in os.curdir is a rather fragile idea.
Barry Warsaw
Amaury Forgeot d'Arc
Marc-André Lemburg
Brett Cannon
Hirokazu Yamamoto
Jesse Noller
Ronald Oussoren
Mark Hammond
Thomas Heller
Georg Brandl
Martin v. Löwis
Alexandre Vassalotti
Andrew M. Kuchling
Christian Heimes
Benjamin Peterson
Thomas Wouters
Fred Drake
Trent Nelson
Guido van Rossum
Skip Montanaro
Neal Norwitz
Matthias Klose
Phillip J. Eby
Tim Peters
Bob Ippolito
Trent Mick
Armin Rigo
Anthony Baxter