the only user of this is Lib/distutils/tests/test_build_ext.py (in order
to find the source for xxmodule.c). I'm not sure if other platforms
need similar tweaks, I'm not brave enough to attempt it without being
able to test.
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.
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.
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.
