set the MACOSX_DEPLOYMENT_TARGET env variable for the interpreter process
on OS X. This could cause failures in non-distutils subprocesses and was
unreliable since tests or user programs could modify the interpreter
environment after distutils set it. Instead, have distutils set the
the deployment target only in the environment of each build subprocess.
Continue to use the previous algorithm for deriving the deployment target
value:
if MACOSX_DEPLOYMENT_TARGET is not set in the interpreter's env:
use the interpreter build configure MACOSX_DEPLOYMENT_TARGET
elif the MACOSX_DEPLOYMENT_TARGET env value >= configure value:
use the env MACOSX_DEPLOYMENT_TARGET
else: # env value less than interpreter build configure value
raise exception
This allows building extensions that can only run on newer versions of
the OS than the version python was built for, for example with a python
built for 10.3 or later and an extension that needs to be built for 10.5.
Without this patch python will fail to start properly when the environment
variable MACOSX_DEPLOYMENT_TARGET is set on MacOSX and has a value that is
not compatible with the value during Python's build. This is caused by code
in sysconfig that was only meant to be used in disutils.
This was overlooked in r80804. This change is not really a bug fix,
but the release manager agreed to it. There is no NEWS entry, like
in the original commit.
to "sys.platform == 'mac'" and that is
dead code because it refers to a platform
that is no longer supported (and hasn't been
supported for several releases).
Fixes issue #7908 for the trunk.
on OSX. Without this patch it wasn't possible after all
to compile extensions on OSX 10.6 with the binary
installer unless the user had installed the (non-default)
10.4u SDK.
ignores the '-isysroot' option on OSX when the
corresponding SDK is not installed.
This ensures that the user can compile extensions
on OSX 10.6 using the Python.org installer and a
default installation of Xcode.
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.
to make using "-undefined dynamic_lookup" for linking extensions more
automatic on 10.3 and later. So if we're on that platform and
MACOSX_DEPLOYMENT_TARGET is not set we now set it to the current OSX
version during configure. Additionally, distutils will pick up the
configure-time value by default.
Will backport.
of hard linking against the framework).
If $MACOSX_DEPLOYMENT_TARGET is set, and >= 10.3, during configure we
setup extensions to link with dynamic lookup. We also record the
value in the Makefile.
Distutils checks whether a value for MACOSX_DEPLOYMENT_TARGET was
recorded in the Makefile, and if it was insists that the current
value matches.
This is only a partial fix because it only applies to 2.4, and the
"two python problem" exists with Python 2.3 shipped with MacOSX 10.3,
which we have no influence over.
The two long lines have been reflowed differently; hopefully someone on
BeOS can test them. Rev. 1.53 also converted string.atoi() to int(); I've
left that alone.
Ned Deily
Ronald Oussoren
Éric Araujo
Antoine Pitrou
Tarek Ziadé
Neil Schemenauer
Trent Nelson
Guido van Rossum
Marc-André Lemburg
Christian Heimes
Armin Rigo
Martin v. Löwis
Tim Peters
Brett Cannon
Jack Jansen
Anthony Baxter
Andrew M. Kuchling
Jeremy Hylton