cpython.git - https://github.com/python/cpython.git

	Commit message (Collapse)	Author	Age	Files	Lines
*	This check-in fixes two problems:	Ronald Oussoren	2010-04-08	1	-2/+2
\| \| \| \| \| \| \| \|	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.
*	Fix for issue #7998: pythonw didn't work when --with-framework-name was	Ronald Oussoren	2010-03-07	1	-1/+1
\| \| \| \|	specified
*	- Issue #7658: Ensure that the new pythonw executable works on OSX 10.4	Ronald Oussoren	2010-01-17	1	-6/+29
\| \| \| \| \| \| \| \| \| \| \| \|	- Issue #7714: Use ``gcc -dumpversion`` to detect the version of GCC on MacOSX. - Make configure look for util.h as well as libutil.h. The former is the header file that on OSX contains the defition of openpty. (Needed to compile for OSX 10.4 on OSX 10.6) - Use the correct definition of CC to compile the pythonw executable
*	Issue #6834: replace the implementation for the 'python' and 'pythonw' ↵	Ronald Oussoren	2009-12-24	1	-5/+135
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	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.
*	Move Mac/OSX/Tools one level up	Ronald Oussoren	2006-06-07	1	-0/+17