svn+ssh://pythondev@svn.python.org/python/trunk
........
r81649 | ronald.oussoren | 2010-06-02 05:47:14 +0200 (Wed, 02 Jun 2010) | 5 lines
Fix for issue8868: without this patch 'MacOS.WMAvailable()' will return
False on MacOSX 10.5 or earlier and scripts won't be able to access GUI
functionality.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r80647 | ronald.oussoren | 2010-04-30 13:20:14 +0200 (Fri, 30 Apr 2010) | 11 lines
Fix for issue #3646: with this patch it is possible to do a
framework install of Python in your home directory (on OSX):
$ configure --enable-framework=${HOME}/Library/Frameworks
$ make && make install
Without this patch the framework would get installed just fine,
but 'make install' would try to install the application bundles
and command-line tools outside the user's home, which doesn't work
for non-admin users (and is bad form anyway).
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r80232 | ronald.oussoren | 2010-04-20 07:50:44 +0200 (Tue, 20 Apr 2010) | 3 lines
Explicitly set system default for $PATH to
ensure we have a clean build environment (OSX installer)
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r80179 | ronald.oussoren | 2010-04-18 16:01:05 +0200 (Sun, 18 Apr 2010) | 5 lines
Add check to build-installer.py to ensure that
the right version of Tcl/Tk is available (on OSX)
Fixes issue #5651
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r79902 | ronald.oussoren | 2010-04-08 03:13:31 -0500 (Thu, 08 Apr 2010) | 9 lines
This check-in fixes two problems:
1) A non-critical off-by-one error in pythonw
2) A problem in the configure script that caused
builds with '--enable-framework --enable-universalsdk=/'
to fail on OSX 10.6.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r77031 | ronald.oussoren | 2009-12-24 14:30:58 +0100 (Thu, 24 Dec 2009) | 15 lines
Issue #6834: replace the implementation for the 'python' and 'pythonw' executables on OSX.
The previous implementation used execv(2) to run the real interpreter, which means that
you cannot use the arch(1) tool to select the architecture you want to use for a
universal build because that only affects the python/pythonw wrapper and not the actual
interpreter.
The new version uses posix_spawnv with a number of OSX-specific options that ensure that
the real interpreter is started using the same CPU architecture as the wrapper, and that
means that 'arch -ppc python' now actually works.
I've also changed the way that the wrapper looks for the framework: it is now linked to
the framework rather than hardcoding the framework path. This should make it easier to
provide pythonw support in tools like virtualenv.
........
