| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
As of 2.7.8, the 32-bit-only installer will support OS X 10.5
and later systems as is currently done for Python 3.x installers.
For 2.7.7 only, we will provide three installers:
the legacy deprecated 10.3+ 32-bit-only format;
the newer 10.5+ 32-bit-only format;
and the unchanged 10.6+ 64-/32-bit format.
Although binary installers will no longer be available from
python.org as of 2.7.8, it will still be possible to build from
source on 10.3.9 and 10.4 systems if necessary.
|
| |
|
|
| |
to the internal Mac/README file.
|
| |
|
|
|
| |
OS X 10.8 systems because the Apple-deprecated QuickDraw headers have
been removed from Xcode 4. Skip building it in this case.
|
| |
|
|
| |
found by Serhiy Storchaka and Matthew Barnett
|
| |
|
|
| |
(Patch by Dionysios Kalofonos)
|
| |
|
|
| |
Mac/README. Fixes issue 7107.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
| |
building a universal Python. Based on issue7679.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
to that README file with some explanation.
* Be more strict in the configure script: complain loudly when the user has
specified invalid combinations of OSX-specific configure arguments.
The error message refers to the Mac/README file for more information.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
