of OPT for special build options. By setting OPT, some compiler-specific
options like -fwrapv were overridden and thus not used, which could result
in broken interpreters when building with clang.
64-bit/32-bit installer for 10.6+. It is no longer necessary
to install a third-party version of Tcl/Tk 8.5 to work around the
problems in the Apple-supplied Tcl/Tk 8.5 shipped in OS X 10.6
and later releases.
of OPT for special build options. By setting OPT, some compiler-specific
options like -fwrapv were overridden and thus not used, which could result
in broken interpreters when building with clang.
1. ppc arch detection for extension module builds broke with Xcode 5
2. ppc arch detection in configure did not work on OS X 10.4
3. -sysroot and -arch flags were unnecessarily duplicated
4. there was no obvious way to configure an intel-32 only build.
64-bit/32-bit installer for 10.6+. It is no longer necessary
to install a third-party version of Tcl/Tk 8.5 to work around the
problems in the Apple-supplied Tcl/Tk 8.5 shipped in OS X 10.6
and later releases.
- Remove OS X installer and Mac/Makefile dependencies on /Developer which
no longer exists with Xcode 4; the referenced tools have been installed
into the usr/bin tool root since Xcode 3.
- Support adding the SDK usr/bin tool root to the installer's PATH via the
SDK_TOOLS_BIN environment variable.
different parsing of the Makefile by distutils.sysconfig and
sysconfig in the case when an intermediate config vars, used to
construct PY_CFLAGS or PY_LDFLAGS, has a trailing space character.
In this case, the OS X installer build script was leaving a
trailing space in the OPT and LDFLAGS config vars. The space is not
significant and it's not worth toying with the Makefile parsing.
build paths from configuration variables cached in _sysconfigdata.py, as
is already done for the installed Makefile. This avoids a distuils test
case failure in test_ldshared_value.
properly skip uncompilable files and to compile existing
files in site-packages if reinstalling. Also, no longer
attempt to install a documentation link in /Developer
as that no longer necessarily exists with Xcode 4.3+.
installer package from the OS X Makefile for Python 3. It has
never worked on Python 3 and is not needed there as pre-10.3.9
installs are no longer supported.
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r88475 | ned.deily | 2011-02-21 12:44:27 -0800 (Mon, 21 Feb 2011) | 3 lines
Issue #11268: Prevent Mac OS X Installer failure if Documentation
package had previously been installed.
........
the system-provided Python. Also, properly guard a new Python 3 only
installer build step so that build-installer.py can stay compatible
with the 2.7 version. (with release manager approval for 3.2rc2)
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r88007 | ned.deily | 2011-01-14 21:44:21 -0800 (Fri, 14 Jan 2011) | 5 lines
Remove spurious copy of Mac/IDLE/idlemain.py left over from
conversion from Python 2 build process. The correct version
is in Mac/IDLE/IDLE.app/Contents/Resources/
........
svn+ssh://svn.python.org/python/branches/py3k
........
r87791 | georg.brandl | 2011-01-06 11:05:26 +0100 (Do, 06 Jan 2011) | 1 line
#10844: update copyright years in Mac plists.
........
Both the Makefile and the script that is used on OSX to create the binary
installer refer to the directory containing the Makefile using the name
'config'. This name was changed with the new ABI (with default build flags
it is now named config-3.2m). This patch ensures that both files use the
correct name.
The build-installer.py script contains one other change: it now tests for the
Tcl/Tk framework version by looking at the 'Current' symlink in the framework
instead of runnning a script. This makes it possible to verify the version
that is in the SDK that's used during the build instead of the version that
is installed on the system.
Builds are not yet fully supported on Python 3 as some parts
of the build process (like the documentation build chain)
are still dependent on Python 2.
Without this patch the i386/x86_64 installer for OSX 10.6
lies in the ReadMe file and the "Important Information" screen
of the installer (that is, the installer claims it supports
the i386 and ppc architectures insetead of the ones it really
supports)
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r85059 | ronald.oussoren | 2010-09-28 15:57:58 +0200 (Tue, 28 Sep 2010) | 5 lines
Add support for the ZSH shell to the "Update Shell Profile" script
on MacOSX.
Patch by Sylvain Mora, issue #9701.
........
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/branches/py3k
................
r80185 | ronald.oussoren | 2010-04-18 17:24:17 +0200 (Sun, 18 Apr 2010) | 12 lines
Merged revisions 80179 via svnmerge from
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
........
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/branches/py3k
........
r79119 | benjamin.peterson | 2010-03-19 16:42:45 -0500 (Fri, 19 Mar 2010) | 1 line
update mac installer script from the trunk #8068
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r78063 | ronald.oussoren | 2010-02-07 12:46:38 +0100 (Sun, 07 Feb 2010) | 4 lines
Mention a configure warning that almost certainly indicates that
configure is picking up a library that doesn't contain all architectures
required for a universal build on OSX.
........
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.
........
* Remove junk documentation resources from the Python.app inside the framework
(This is a left-over from the ancient Python IDE, which was removed before 2.5)
* Ensure that the documentation is installed in a location where IDLE will see it
svn+ssh://pythondev@svn.python.org/python/trunk
........
r70802 | ronald.oussoren | 2009-03-31 08:20:45 -0500 (Tue, 31 Mar 2009) | 4 lines
Minor update to OSX build-installer script, needed
to ensure that the build will succeed in a clean
checkout and with a non-default deployment target.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r70737 | ronald.oussoren | 2009-03-30 14:34:51 -0500 (Mon, 30 Mar 2009) | 6 lines
* Set a custom icon on the Python installer DMG
* Remove last traces of "MacPython"
* Add options to build different flavors of the installer
(still defaulting to a 2-way universal build that
runs on OSX 10.3)
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r70735 | ronald.oussoren | 2009-03-30 14:22:56 -0500 (Mon, 30 Mar 2009) | 3 lines
Remove usage of the deprecated '-cString' and '+stringWithCString:' API's
in PythonLauncher, replacing them with the correct counterparts.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r70727 | ronald.oussoren | 2009-03-30 12:15:29 -0500 (Mon, 30 Mar 2009) | 5 lines
* Updates installed dependencies to latest releaases (bzip, zlib, ...)
* Changes code for updating folder icons from Python code
that uses the deprecated Carbon module to a much simpler
Cocoa program in Objective-C
........
This update makes sure that the installer won't write files
in /usr/local/bin by default. The installer also won't
replace /Library/Frameworks/Python.framework/Version/Current.
Both to ensure that the installer doens't break an existing
install of python 2.x.
This the build machinery on OSX to re-enable building (and installing)
PythonLauncher.app and IDLE.app.
This needs ports of fixes to Lib/distutils/util.py and Include/pymacconfig.h
to be fully functiontional, to be fully functional.
I also have a patch for Makefile.pre.in that I'll post on bugs.python.org
for review.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r64446 | facundo.batista | 2008-06-21 19:43:56 +0200 (Sat, 21 Jun 2008) | 4 lines
Fixed issue #2888. Now the behaviour of pprint when working with nested
structures follows the common sense (and works like in 2.5 and 3.0).
........
r64490 | thomas.heller | 2008-06-23 21:51:41 +0200 (Mon, 23 Jun 2008) | 1 line
Include debug info when assembling win64.asm in a debug build.
........
r64495 | benjamin.peterson | 2008-06-24 04:41:08 +0200 (Tue, 24 Jun 2008) | 1 line
minor fix
........
r64526 | mark.dickinson | 2008-06-25 17:29:32 +0200 (Wed, 25 Jun 2008) | 2 lines
issue #3199: Fix typo in Mac/Makefile.in
........
r64567 | mark.dickinson | 2008-06-28 00:20:14 +0200 (Sat, 28 Jun 2008) | 3 lines
Fix typo in configure.in, and propagate configure.in changes from r64002
to configure and pyconfig.h.in.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r63955 | ronald.oussoren | 2008-06-05 14:58:24 +0200 (Thu, 05 Jun 2008) | 20 lines
MacOS X: Enable 4-way universal builds
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.
........
Removal of the Mac modules broke many of the Mac scripts (including
BuildApplet.py) so the building of the Python launcher and IDLE.app was
broken. I manually copied built versions of those apps into Mac. Everything else
which used Mac modules had to die.